Skinning Techniques in Web Applications

Transcription

Skinning Techniques
in Web Applications
„Master Thesis of:”
Amagoia Apaolaza Ibañez
Semester:
10.th
Advisor:
Prof. Dr. Jacques Calmet
Tutor :
Dipl. Math. Klaus Beuse
Institute for Algorithms and Cognitive Systems
University of Karlsruhe (T.H.)
“Hereby, I declare this thesis to be the work of my own, written independently. All the
sources and references are correctly cited with complete references to their sources.”
Berlin, 30 March 2006
Amagoia Apaolaza
Gratitude:
First of all, I would like to thank my advisor, Prof. Dr. Jacques Calmet, for having accepted to
advise my diploma thesis and having helped me to carry it out.
Secondly, I thank the whole ICN (Information and Communication Networks) department of
SIEMENS AG, for firstly proposing me a very interesting topic for my diploma thesis and for
having also offered me the chance to doing it for them, putting all their server installations
and web applications at my disposal.
I am particularly grateful to Klaus Beuse, who has been the main tutor of my work in
Siemens, to Eckhard Mauersberger, who has helped me especially with the practical part of
the diploma thesis, to Henry Hübler and Thomas Schneider, for having read my work and
having helped me every time I needed it during the whole time I have been working in my
diploma thesis. I would like to thank the rest of people of the department where I have been
working, for having also contributed to make the time I was at Siemens very pleasant.
1 Introduction: Overview
4
0 Table of contents
0
TABLE OF CONTENTS ...................................................................... 4
1
INTRODUCTION.................................................................................. 9
1.1
Overview ........................................................................................ 9
1.2
Motivation ....................................................................................11
1.3
State-of-the-Art............................................................................14
1.4
Overview of the expected results .............................................15
2
EXPOSITION OF THE TECHNIQUE OF SKINNING .......................17
2.1
Introduction to Skinning technique..........................................17
2.1.1
Definition of Skinning ............................................................................... 17
2.1.2
Model-View-Controller (MVC) Design Pattern.......................................... 18
2.1.2.1
MVC for Web Sites ......................................................................................... 20
2.1.3
Skins and Themes ................................................................................... 21
2.1.4
Graphical examples of a skinnable program ............................................ 22
2.1.5
Groups of Skins and Themes .................................................................. 23
2.1.6
Where and why is Skinning used? Areas of application of Skinning......... 25
2.1.7
Technique of Skinning ............................................................................. 27
2.1.7.1
What must be done to skin an application? ................................................... 28
2.1.7.2
How can all these Skins and Themes be obtained?...................................... 28
2.1.7.3
How can they be installed? ............................................................................ 29
2.1.7.4
Which kind of programs must or could be used?........................................... 29
2.1.7.5
Conclusion ...................................................................................................... 29
2.1.8
Advantages and disadvantages of Skinning ............................................ 30
2.1.9
Limitations of Skinning: Existing patents .................................................. 33
2.1.9.1
Patent 1........................................................................................................... 33
2.1.9.2
Patent 2........................................................................................................... 34
2.1.9.3
Patent 3........................................................................................................... 34
2.2
Deployment of Skinning Methods ............................................35
2.2.1
Skinning methods: Introduction................................................................ 35
2.2.2
Skinning methods: Classification and description .................................... 35
2.2.2.1
Method 1: Skinning method for java coded web applications ....................... 37
2.2.2.2
Method 2: Skinning method for web sites to be skinned by end-users ......... 38
2.2.2.3
Method 3: Skinning method with the use of XML technologies..................... 41
2.2.2.4
Method 4: Skinning method for ASP.NET web applications ......................... 43
2.2.2.5
Method 5: Skinning method for web applications based on XML and CGI... 44
2.2.2.6
Method 6: Skinning method with the skinnable classes of Java Swing ........ 45
2.2.2.7
Method 7: Skinning method with the AWT classes of Java........................... 45
2.2.3
2.3
Advantages/Disadvantages of the methods ............................................. 47
Deployment of Skinning Tools..................................................49
2.3.1
Skinning tools: Introduction...................................................................... 49
2.3.2
Possible alternatives to classify the skinning tools ................................... 49
2.3.2.1
Alternative 1 for a classification: General or specific for a program .............. 50
2.3.2.2
Alternative 2 for a classification: Functionality ............................................... 50
2.3.2.3
Alternative 3 for a classification: Operating system or framework................. 50
2.3.2.4
Alternative 4 for a classification: Programming language.............................. 50
2.3.2.5
Alternative 5 for a classification: Proprietary or standalone tools.................. 51
2.3.2.6
Alternative 6 for a classification: Areas of application of Skinning ................ 51
2.3.2.7
Alternative 7 for a classification: Appliance of MVC model ........................... 51
2.3.3
2.4
3
5
Skinning tools: Overview.......................................................................... 51
Typical boundary conditions (performance, security)...........55
EVALUATION AND APPLIANCE OF SKINNING AT AN EXISTING
WEB SERVER .........................................................................................56
3.1
Introduction .................................................................................56
3.2
Free-Call-Button: Description of the web application............58
3.2.1
Description of the work environment ........................................................ 58
3.2.2
Technical aspects of FcB......................................................................... 60
3.2.3
HTML-pages of FcB................................................................................. 60
3.2.4
Architectures of FcB ................................................................................ 62
3.2.4.1
Architecture 1.................................................................................................. 63
3.2.4.2
Architecture 2.................................................................................................. 63
3.2.4.3
Architecture 3.................................................................................................. 64
3.2.5
3.3
Existing solution to customize FcB........................................................... 65
Skinning Model: how to customize a Web Application .........67
3.3.1
Considerations to decide an adequate solution........................................ 67
3.3.2
Description of the solution........................................................................ 68
3.3.2.1
The HTML Template....................................................................................... 71
3.3.2.2
The CSS file and support of browsers ........................................................... 73
3.3.2.3
The XML file.................................................................................................... 74
3.3.2.4
The Servlet...................................................................................................... 86
3.3.2.5
Solution particularized for the three architectures ......................................... 90
3.3.2.6
Graphical examples of the solution ................................................................ 91
3.3.2.7
Skinning the applet ......................................................................................... 95
3.3.2.8
Other existing HTML sites in the FcB application ........................................ 100
3.3.3
What must the provider do to customize the sites of a new client .......... 102
3.3.4
Possibilities and limitations of this method ............................................. 103
3.3.4.1
Possibilities: What can be skinned............................................................... 103
3.3.4.2
Limitations: What can not be skinned .......................................................... 104
3.3.5
Problems and difficulties during the practice .......................................... 105
3.3.6
Advantages and disadvantages ............................................................. 107
3.3.6.1
Advantages................................................................................................... 107
3.3.6.2
Disadvantages .............................................................................................. 108
3.4
4
6
Conclusion and evaluation......................................................109
CONCLUSION AND ACHIEVEMENTS OF THE THESIS .............110
7
4.1
Summary of the master thesis ................................................110
4.2
Achieved results .......................................................................115
4.3
Possible points of extension...................................................117
5
GENERAL INFORMATION.............................................................119
5.1
Abbreviations ............................................................................119
5.2
Glossary .....................................................................................120
5.3
References.................................................................................124
5.3.1
Links ...................................................................................................... 124
5.3.2
Literature ............................................................................................... 126
5.4
6
List of figures, tables and lists................................................127
5.4.1
Figures .................................................................................................. 127
5.4.2
Tables.................................................................................................... 128
5.4.3
Lists ....................................................................................................... 129
APPENDIX .......................................................................................130
6.1
Description of commercial tools.............................................130
6.1.1
Introduction............................................................................................ 130
6.1.2
MICROSOFT: ........................................................................................ 131
6.1.2.1
Xheo.WebSkin .............................................................................................. 131
6.1.2.2
ActiveSkin ..................................................................................................... 134
6.1.2.3
Skinboxer ...................................................................................................... 135
6.1.2.4
EZSkin .......................................................................................................... 137
6.1.2.5
ExSkin........................................................................................................... 137
6.1.2.6
DirectSkin (Stardock tool)............................................................................. 138
6.1.2.7
Object Desktop (Stardock tool) .................................................................... 138
6.1.2.8
WinCustomize (Stardock tool)...................................................................... 140
6.1.3
Platform independent: programming language: C++ and Delphi............ 140
8
6.1.3.1
Skinux ........................................................................................................... 140
6.1.3.2
TMS Skin Factory ......................................................................................... 142
6.1.4
Platform independent: programming language: JAVA............................ 143
6.1.4.1
Action Servlet................................................................................................ 143
6.1.4.2
SkinLF (Skinapplet, Skinit) ........................................................................... 144
6.1.4.3
Pajes ............................................................................................................. 145
6.1.5
Platform independent: programming language: Visual Basic ................. 146
6.1.5.1
6.1.6
vbAccelerator NeoCaption Component ....................................................... 146
Platform independent: application dependent tools................................ 148
6.1.6.1
SAP Editor .................................................................................................... 148
9
1 Introduction
Outline: In this introductory chapter, an overview of the content of the master thesis,
together with the motivation of having written it and the expected results are presented.
1.1
Overview
The purpose of this master thesis is to make a complete report of the relatively new concept
of Skinning. It will be presented not only a theoretical study, but also a practical one, so that
all the knowledge acquired in theory can also be tested and demonstrated in an existing web
application.
Basically, two main blocks constitute the present document:

The theoretical study: Exposition of the technique of Skinning (Chapter 2)

The application to practice: Evaluation and appliance of Skinning at an existing web
server (Chapter 3).
Besides these principal chapters, two more ones complement the content of the thesis: this
first chapter that introduces the topic, and chapter 4, which includes a brief summary of the
content of the whole document, a conclusion with all results that have been achieved during
the period of work, and also an exposition of the possible points of extension of this master
thesis.
The last two chapters contain only the general information (chapter 5) such as the glossary,
the abbreviations list, the references (links and literature), lists of tables and figures in the
master thesis, and finally the appendix (chapter 6) that includes some additional information
related mostly to the tools existing on the market.
The objective of the theory is to present the topic of Skinning in its whole sphere of activity. In
general terms, chapter 2 is divided in four main sections, which can be considered as the
State-of-the-Art of Skinning, because they expose what is till now done in reference to the
topic. However, it must be noticed here that so an exposition of this issue, in the way that it is
10
presented in this master thesis had been never made before, due to the newness of the
subject. The following points describe the four sections of chapter 2:

An introduction to the topic: definition, areas of application, advantages and
disadvantages of utilization, existing patents, etc. (section 2.1)

The presentation of a set of methods to skin an application (section 2.2)

The exposition of the existing skinning tools on the market (section 2.3)

Typical boundary conditions (performance, security) of the presented skinning
methods and tools (section 2.4)
The practical part of the master thesis is based on an Industry Example, where the technique
of Skinning has been applied to customize a certain web application. The objective of this
part of the thesis is to present a suitable skinning method for web applications. It will be
tested in a certain environment of work, but it is also expected to demonstrate that it is not
only appropriate for the conditions in which it has been tested, but also for any other web
application of any other characteristics. The main sections of this chapter are:

Introduction to the Industry Example (section 3.1)

Description of the web application to work with (section 3.2)

Description of the proposed Skinning method (section 3.3)

Conclusion and evaluation of the presented method (section 3.4)
Finally, chapter 4 presents an interesting summary of the whole work related to the master
thesis, together with the general conclusions, and the exposition of those points of possible
extension of the topics that have been dealt along this master thesis.
1 Introduction: Motivation
1.2
11
Motivation
Nowadays, the new tendency of produced software with a Graphical User Interface (GUI) is
to offer its users the possibility of modifying it with their own style. This recent feature of
programs makes them much more attractive for end-users because the vast majority likes to
differentiate him/herself from everybody else, as it usually occurs in the ordinary life.
The question now should be how this attracting characteristic of software-programs can be
achieved and it is there where the concept of Skinning comes into play. There are plenty of
new applications that make it feasible to change the appearance or layout of their user
interface and offering it, means a factor of success against their competitors, just because
users like it.
Moreover, it will be in this master thesis demonstrated that Skinning is not only a fashion
feature, as it at first can seem, but also a necessity for the user (for instance: choice of the
most appropriate colors for blind people, etc.). These are some of the most significant
reasons to consider Skinning as a matter of study; however there are of course other
relevant causes of motivation for this master thesis, which are cited in the next list (List 1.2.1)
and commented in the following paragraphs.
First of all, Skinning is a relatively recent issue and there are almost no research works about
it. Though there are a lot of programs that use this technique, little documentation exists that
explains how they achieve it. This master thesis presents therefore, a complete exposition of
the subject, which had never been done before.
Secondly, it is the first time that a deep study and data collection about all possible skinning
methods (section 2.2) and tools (section 2.3) are presented. Neither a classification of these
methods, attending to different criteria, nor a deployment of commercial existing tools, like
the one presented in the current master thesis, have been shown before. Unfortunately, no
standards and literature exist about the specific topic of Skinning, which supports even more
the fact that no proper technology about it has been yet created. Although some research
works about it can have been done, they have been still not important enough to make
Skinning a standard technology. Therefore, it is still considered as an absolute young topic,
waiting to be developed and deployed in software that needs an advanced GUI. The fact that
there is no accurately well-organised documentation relating to the topic of Skinning, as a
subject of research, could seem to be a difficulty to carry out this work, but it is actually
another relevant reason of having written about it.
12

The actuality and newness of Skinning: it is an up-to-date technique

The variety of functionalities of Skinning: it is not only a matter of pretty layouts
but the way to add helpful and useful properties to GUIs (suitable colors for blind
people, etc.)

The lack of research and standard-works about the technique of Skinning: it will
be the first time that so an exposition of the technique of Skinning is done

The classification of skinning methods and exposition of commercial tools that
it is here presented, has been never done before

The customization and personalization of any GUI can be achieved with the
use of Skinning

Introduction of a new area of application of Skinning that does not take place at
the end-user side, but between the provider and the business customer (B2B)

Skinning will also play an important role in the internationalization and
localization of applications
List 1.2.1: Reasons of interest in writing about Skinning
Moreover, what is mostly known about Skinning up to now references mostly to the capability
of the end-user to modify the layout at run-time (personalization), but there is also another
interesting and important use of case to take into account. Therefore, in the current master
thesis, it will not be uniquely considered this attractive (especially for the end-user) aspect of
Skinning but also other aspects of its utility, which make the development of flexible and
customizable software possible. As a general example, a software-developer could wish to
create a customizable application to offer a different layout to every of his/her clients.
Skinning would be here again a suitable solution, although it is not the end-user, who alters
the external appearance of the application, but the developer him/herself.
The previous example introduces indirectly the second area of application, which could even
be a new branch of research in the Skinning topic, and that is also here firstly presented. It
has relation to the evident desire of a corporation of having its personal style (Corporate
Identity), which is, to some extent, connected to the cited case of the developer customizing
his/her own application for each of his/her customers. When big companies buy any
software-product or application, they like that the products are already outfitted in their own
13
branding, and not in the one of the developers-enterprise. That is why flexibility is one of the
foremost product design goals in the development of all new applications. Where flexibility
takes place, should also be Skinning involved. This new point of view is also expatiated in
this master thesis. In fact, the Industry Example exposed in chapter 3, adjusts itself perfectly
to this new area of development of Skinning. The example will be implemented in one of the
Web Services of the company SIEMENS AG and also tested in one of its servers.
The department in charge of the new Multimedia products of SIEMENS has developed
different network applications (SURPASS hiQ4000-products) to be utilized by a large number
of customers. The objective is to design the web pages that are part of the Web Service, with
the personal style of each customer (customization). Due to the huge amount of clients, the
task of customizing every of them could be extremely tedious. The use of any of the methods
or tools that implement the technique of Skinning could be the solution to this problem. Either
the choice of the best one from the presented methods and tools, or the adaptation of one of
them for this certain Industry Example, is also an interesting point to consider in the master
thesis. It could be also possible that none of the methods or tools from the theory were
suitable to solve the problem, and a new model had to be created.
Furthermore, the matter to be solved for SIEMENS AG is not only related to the images,
colors, and GUI, but also to the language (internationalization and localization) of the
application. The Web Services of SIEMENS will be offered all over the world and they must
be therefore available in different languages. The use of these two items is already
widespread in the development of software, since the companies try more and more to come
on to the international market. The words are so often used that many authors have begun to
call them in a shorter way: i18n and l10n are the abbreviations of internationalization and
localization respectively. The numbers 18 and 10 indicate the number of letters that are
found between the first and the last letter of the word, that is, in the word
“internationalization”, there are 18 characters between the “i” and the “n”, while in
“localization”, there are just 10 letters between the “l” and the “n”. The use of Skinning in
order to achieve internationalized and localized software is another point to be evaluated in
this thesis. As it will be demonstrated in chapter 3, the i18n and l10n of an existing web
application can be one of the most problematic matters to be handled in the practice.
Finally, once that all different reasons of motivation have been summarized, the why and
wherefore of making this master thesis is still more obvious. It must be only put together all
new ambits, in which Skinning could be present, with the absence of research up to now
about this topic, to demonstrate the huge interest in writing about it
1 Introduction: State-of-the-Art
1.3
14
State-of-the-Art
In this section, I will briefly describe the State-of-the-Art of the technique of Skinning. Chapter
2 could be considered, to a large extent, as the State-of-the-Art because, as it was already
mentioned in the first section (1.1) of this chapter, all that has been done till now in relation to
the topic of Skinning will be exposed in chapter 2.
Anyway, what is known and mostly used in relation to the topic of Skinning is presented in
the following list (List 1.3.1):

A definition of the concept of Skinning has been more than once presented, but an
official definition has not been written yet

Use of Skinning in different well-known SW applications in PC (Browsers, Desktops,
MP-3 Playes, etc), which are designed to be skinned especially by the end-user

Existence of particular tutorials to learn how to skin some of the well-known
skinnable programs

Existence of tutorials to learn how to create and design the Skins for a certain
program

Existence of a set of commercialized tools to skin certain applications

Set of articles and reviews in Internet about the topic of Skinning. Some of them
suggest different ways to achieve a skinnable application, not only in PC but also on
the Web
List 1.3.1: Summary of points of the State-of-the-Art of Skinning
I do not want to extend this section much more now because the whole chapter 2 will present
all these aspects in detail. I only wanted to make a short touch to the State-of-the-Art in this
introductory chapter, before starting with the theoretical study, in order to give the reader an
idea about what can be found in the actuality about Skinning.
1 Introduction: Overview of the expected results
1.4
15
Overview of the expected results
This section outlines the objectives and expected results of the master thesis. The following
lists make reference to the expected results of theoretical (List 1.4.1) and practical work (List
1.4.2) respectively.

Complete exposition of the topic of Skinning with the categorisation of all the found
information: it is expected that any reader of the master thesis becomes the
information that he/she may need about Skinning (features, applications,
advantages and disadvantafes, boundary conditions, etc)

Exposition of different skinning methods classified by different criteria and described
in full detail

Overview of existing skinning tools on the market and description of their main
features and functionality

Suggestion of a suitable method/tool to be applied in the Industry Example of
Siemens
List 1.4.1: Expected results from the theoretical work

Presentation of a method/tool that is able to skin any web application

Use of this method in a certain Web Service of Siemens and its evaluation

Customization and Personalization of the Web Service with the use of the
implemented method: it is expected that the web application to work with becomes
skinnable, so that each customer can have the UI he/she wishes

Internationalization and Localization of the web service with the use of the
implemented method: it is expected that the web application can be adapted to any
country, which means the change of the language and the adjustment of all those
characteristics that are typical from a certain place of the world (way of writing the
date, direction of writing etc.)
List 1.4.2: Expected results from the practical work
1 Introduction: Overview of the expected results
16
With these previous two objectives lists finishes this introductory chapter and starts the body
of the master thesis, first with the theory and next with the practice.
In chapter 4, I will make reference again to all these expected results, with the appropriate
comments about them and a more wide evaluation about what I achieved, which problems
and difficulties I had, and the set of points that could be extended in future works of research
about this topic.
2 Exposition of the technique of Skinning: Introduction to Skinning technique
17
2 Exposition of the technique of Skinning
Outline: This chapter presents the first main block of the document and contains the whole
theoretical study and research of the master thesis.
2.1
Introduction to Skinning technique
The purpose of this first introductory section is to give a general overview of all what the
concept of Skinning involves. The definition and explanation of related terms, a list of
examples, and areas of application of Skinning, together with a table of advantages and
disadvantages of its utilization, complete this section.
2.1.1
Definition of Skinning
In principle, there is no standard definition of the term Skinning and neither a common one
between all those sources where the concept is defined. Therefore, the explanation that will
be presented here is just the conclusion of considering the existing information about them.
The meaning of the term Skinning can be assumed from the word itself: it refers to the ability
of the application to change its skin, that is, to alter the appearance of it. Skinning is till now
considered to affect mostly the layout of the applications but also in some extends, the
functionality or behaviour of them. The use of the word Skinning in skinnable software makes
always reference to the modification of the GUI and in some cases, not only the images and
sounds, but also the text (language) may be included in the group of skinning elements.
Taking into account all these considerations, my definition for the term “Skinning” is the
following:
“Skinning is the technique that makes it possible to modify automatically the complete
layout of a software application. This means that each user of the application can choose a
different GUI at runtime or that the developer him/herself can change the appearance of
his/her program without having to add any line of code. “
2.1.2
18
Model-View-Controller (MVC) Design Pattern
Since the point of view of the implementation, it is to notice that where Skinning takes place,
the content management and the presentation management must be handled separately.
According to the necessary division between this two fields in every context of Skinning, I
have determined to apply in the whole description of the theoretical work, one of the standard
design patterns for User Interfaces, which casually adapts itself perfectly to this necessity:
the well-known Model-View-Controller (MVC) design pattern, where the business logic
(Model) is separated from the presentation (View). Between both of them must be something
(Controller), which interconnects the other two and allows the communication with each
other. The following figure (Figure 2.1.1) shows a graphical representation of this idea:
Figure 2.1.1: Representation of the MVC design pattern
The reason because of which, I have decided to use a design pattern as support of the
technique of Skinning, is just the search of simplicity and clarity. The fact that this pattern
already exists allows explaining the Skinning concept more clearly and therefore, it permits a
better understanding for the readers of this master thesis.
Nevertheless, the utilization of this standard model in concrete should not be absolutely
necessary to add the feature of skinnability to a program but, as already written, a suitable
way to represent what is actually a requirement in the process of Skinning.
19
In the following subchapters, where the skinning methods (section 2.2.2) and tools (section
2.3.3) are presented, some references to this design pattern will be mentioned again. For
instance, in each of the presented methods, the three different components of the model will
be considered separately and the involved technologies in each method will be also
classified according to its functionality within the MVC-model. On the other hand, in relation
to the tools, in some of them the separation between the three components of MVC model is
obvious and easy to represent, but not all tools give the chance of being classified within this
pattern, mostly because of the lack of information about the technologies they use.
Therefore, since it will be a significant point in the rest of the master thesis, a brief description
of this model is here presented:
The MVC-model consists in dividing the code in three parts:

The data model - the component that handles data in the application

The view - the component that presents the data to the user

The controller - the component that mediates between the model and the view
The MVC abstraction can be graphically represented as follows:
Figure 2.1.2: Mode of operation of the MVC design pattern
(Picture from source: [7.6], section 5.3.1)
How it works (source [7.6], section 5.3.1): Events typically cause a controller to change a
model, or view, or both. Whenever a controller changes a model’s data or properties, all
dependent views are automatically updated. Similarly, whenever a controller changes a view,
20
for example, by revealing areas that were previously hidden, the view gets data from the
underlying model to refresh itself.
Skinning should mostly affect the view, so that when a new skin is chosen, a new view is
presented and the data model must not be changed.
This way the user interface code is decoupled from the code that handles data, and another
component, the controller, is used to provide the interaction between the two. The benefits
are the followings:

Multiple views are possible from the same data model (it is exactly what Skinning
tries to achieve in an automatically way)

Flexibility and re-use (flexibility and re-use are both objectives of using Skins)
2.1.2.1 MVC for Web Sites
Web Sites are, for example, a wide area of application of this pattern. It is more and more
common that designers and developers work separately, which implies that a proper
separation of the content and the presentation must be done. When creating a web
application, it must be dealt with two things: the code (application logic) and the look&feel
(HTML pages). Traditional approaches use two basic methods to deal with both of them:

Code that generates the HTML output - servlets (or CGI scripts etc.)

Code that is embedded in HTML - JSP (or ASP, PHP etc.)
There is no doubt that the use of a template engine (for example, see in section 5.3.1
WebMacro [7.8] or Velocity [7.9]) provides an advance of the programming model - you can
separate Model (data representation), View (HTML template) and Controller (manages the
application flow).
In MVC model, there is almost no code in the HTML templates - just the simple script of the
template engine, which can be easily understood by the web designer, and there is no HTML
embedded in the program (servlet) code.
See the references (from [7.1] to [7.10] in chapter 5.3.1, and literature [10], [11] in subchapter
5.3.2) for more information about MVC.
2.1.3
21
Skins and Themes
Once the term Skinning has been defined in section 2.1.1, two of the related terms to this
technique, Skins and Themes, will be also explained.
The process of Skinning consists actually in replacing any of these Skins/Themes with
another one or just in adding or eliminating Skins/Themes from the layout. They allow the
user to configure the GUI by choosing different categories of Skins.
The difference between the respective definitions of these two terms (Skins and Themes)
may be a bit ambiguous. They could be even replaceable with each other in some cases,
therefore the fact of differentiate them, is more a matter of opinion than a technical one.
In this master thesis, I have presented a small difference in my definitions, though both have
the same functional and technical meaning, as it can be read in the following paragraphs:
“Skin is the set of elements that includes everything necessary to change the look-andfeel of a particular GUI of a certain application. They could include bitmaps for each
element in the layout of the application (buttons, title bars, sliders, radio buttons, check
boxes, borders…). “
“Theme is also a set of elements, but it consists in individual files, which are usually
ordered in directories. They are used for general things above the operating system layer
(for example: the color-patterns of operative systems, background images, etc). On the
contrary, Skins are usually created even for a certain program and they can mostly only
work properly with it”
Though this small difference, as it was already mentioned before, sometimes the two
concepts are not properly differentiated and it occurs that a term is used to make reference
to the other, for example, in Netscape it is called Theme, what in any other case would be
named Skin. Anyway, the difference between both terms is not so relevant for the
explanation of the process of Skinning and neither for the use of it; therefore, it is neither an
essential point of the master thesis. Besides, examples of both categories (Themes and
Skins) are presented in the document (section 2.1.5). It is only necessary to know that Skins
and Themes must be created and used, since both of them are necessary in the process of
Skinning.
2.1.4
22
Graphical examples of a skinnable program
Finally, to complete this introductory section, a couple of pictures are presented to expose
these concepts in a more illustrative way. I have decided to use some examples from the
MP-3 Player Winamp, which is one of the most well known skinnable programs:
Figure 2.1.3: Normal aspect of Winamp
(From source [2.8], section 5.3.1)
Figure 2.1.4: One of the thousand existing Skins for Winamp
Figure 2.1.5: Graphical example of Skins in Winamp
2.1.5
23
Groups of Skins and Themes
In the following table (Table 2.1.1) the different existing examples of Skins and Themes on
the market are presented and grouped together, attending to the kind of application or
program for which they are created. This list represents the variety of programs in which
Skinning can be applied and gives also a good idea of the wide use of it, showing all cases in
which Skins and Themes are respectively used.
For specific programs such as Winamp, Trillian, ICQ, etc, Skins are utilized, whereas for
general applications, for instance, those relative to operating systems, the term Themes is
used, with some exceptions like, for example, the browser Netscape, where Skins are called
Themes.
Another characteristic of Skins and Themes, which is also appreciable on the table (Table
2.1.1), is that some of them have been particularised for a specific part of the layout of an
application, in such a way, that even attributes to name them have been created. These
complete names (hotbar Skins, Surfer Themes, etc.) are widely used to recognise the kind of
Skin/Theme, to which they refer.
All examples of the table (Table 2.1.1) are a small representation of all those web sites (see
chapter 5.3.1, links [1.1]-[1.8]), which offer an amount of Themes or Skins to download and
allow the users to customize their applications. They include also the last news about
anything that makes reference to the topic of Skinning, especially about all those that make
reference to the new methods of Skinning (new specific tutorials) and existence of new Skins
for any skinnable program.
The last two row entries of the table differentiate themselves from the rest of the examples
because there are not certain Skins or Themes created particularly for them, as in the other
examples. However, I have found it convenient to add them at the end of the table, since
they are also possible skinnable applications; firstly private skinnable websites can be
already found in Internet (see examples in section 5.3.1, links [9.1], [9.2] and [9.3]), and
secondly, there are already implemented-classes or functions for some programming
languages, which facilitate or provide the Skinnability in those SW-applications that are
coded with them.
Skins/Themes for:
Skins or Themes
Skinnable examples
Operating Systems
Themes
Linux
Desktop
24
Description
 One of the first expression of the process of
Windows
Skinning was precisely the possibility of modifying
Mac
the layout of operating systems
 Desktop Themes
Desktop of Windows,  They provide a way of changing the manner a
 Screensavers
Linux, Mac, etc.
 Wallpapers
Litestep
 Screensavers, wallpapers and icons can also be
 Icons
Talisman
considered as skins/themes, because they allow the
 Skins for specific
Hoverdesk
user to change the appearance of his/her computer.
programs that make a
EVWM
They are usually classified as Themes.
Desktop skinnable
Nextstart
computer looks and sounds.
Outsider99
StyleXP
Screenshots
WindowBlinds
DesktopX
Browsers
1) Hotbar Skins
1) Internet Explorer
1) They are used to change the look of IExplorer 4
Surfer Themes
and 5 browser bar
2) Browser Skins
2) Neoplanet
2) Neoplanet: one of the first skinnable browsers
3) Browser Themes
3) Netscape, Mozilla
3) Here, the term Themes is used for what actually
should be named Skins
Chat programs
Skins
Trillian, ICQ, Yahoo,
ICQ: chat program that uses ICQPlus to modify its
Messenger
look and feel
Trillian: SkinXML technology (similar to Winamp)
MP-3 programs
Web sites and
Skins
Skins
portals
Winamp, Sonique,
Winamp is one of the first MP-3 players that allowed
Freeamp
giving a brand new look to the program.
SAP portals, private
They allow the end-user to modify the web site they
skinnable sites
visit (they are private skinnable sites that someone
hat implemented applying one of the existing
methods to do it).
The portals refer to the creation of customized
Portals, as for instance, SAP does. They customize
their SW for each of their customers.
Programming
Skins
Java-Swing, Delphi,
There are some programming languages that have
languages with
(No already created
C, C++
libraries
skinning
Skins exist; for each
skinnable applications.
libraries/classes
application new ones
Specific tools exist even to make it easier. They will
must be created)
be exposed in section 2.3.3.
with
implemented
methods
to
code
Table 2.1.1: Examples of Skins and Themes
25
Once that so a long list of examples is presented, there are some important technical
questions to answer, in order to explain the process of Skinning and also the way these
examples of programs operate with its respective Skins or Themes. I have chosen the
following technical matters (List 2.1.1) as the most interesting ones:

What must be done to skin an application?

How are all these Skins and Themes created?

How can they be installed?

Which kind of programs must or could be used?
 …
List 2.1.1: Technical questions about the process of Skinning
These four questions will not be answered just now, but in section 2.1.7. Firstly, I have
decided to expose the areas of application of Skinning (section 2.1.6) in order to situate
better all possible examples of this technique and just afterwards, I will present a general
sketch of the answers to the previous technical questions. In the rest of subchapters of this
theoretical part, especially in those, in which the existing Skinning methods (section 2.2) are
classified and skinning tools (section 2.3) are outlined, a better and more detailed description
of the process of Skinning is explained.
2.1.6
Where and why is Skinning used? Areas of application of Skinning
As it was presented in section 2.1.1, a set of well-known programs offers their users the
possibility to customize the appearance of their GUIs. Therefore, Skinning is mainly used by
the end-user of the application. None of the common areas of utilization refers to Skinning as
a necessity, but as a way for the end-users to enjoy themselves personalizing their software.
All this existing tools that allow for example to skin the desktop, browser or any other specific
program have this same function.
Up to now, one of the main reason of using Skinning has been basically the desire of users
to have their own GUIs absolutely different to the ones of the rest of users and the possibility
of offering an attractive user interface to the customer, but other functionalities of Skinning
have been barely mentioned before.
One of the objectives of this master thesis is precisely to find a new utility of Skinning and
demonstrate it in any of the web server examples provided by SIEMENS ICN.
The reason for SIEMENS, in this case, to use Skinning is to find an easy solution to its
problem of customizing its products SURPASS for each customer. On account of this, the
26
Skinning process has here a complete new area of application, which is entirely different
from what has been till now understood as Skinning. Firstly, because of its functional
objective and secondly, due to the use of Skinning in a B2B relation within a web server
technology and not direct for the end user (B2C) or in a simple B2B relation for a SW
application on PC, as it is till now mostly being applied. Furthermore, there is no standard
literature yet about how to implement this idea at a web server example.
Given all these considerations about Skinning, one might naturally ask him/herself if it makes
sense to change the visual design of professional software. The answer is yes. Companies
are increasingly relying on business software to generate parts of their websites and
intranets, supplying value-added access and information to employees, customers and
partners by linking their entire back-end system to a web interface available from any
computer connected to the Internet. For this reason, the front-end must reflect the branding
of the company whose data is being interacted with. All this is happening increasing over the
Internet and within corporate intranets; for this reason, the visual design of software running
in a Web environment must respond accordingly.
In general terms, on account of all this previous references, two different wide areas of
application of Skinning are considered:

“Provider” area: Application of Skinning Business-to-Business (B2B). Use of
Skinning between providers and their business-customers. In this case, Skinning
process would allow the customization (branding, configuration, and sub-functions),
internationalization and localization of applications. As it was already mentioned
above, this area, within a web environment, will be a new utility of Skinning that is
studied in this master thesis. The Industry Example of Siemens pertains precisely to
this area of application.

“End-Customer” area: Application of Skinning Business-to-Consumer (B2C). Use
of Skinning to permit the end-customer to personalize his/her GUI (personalization).
The end-customer is considered as the end-user and both terms will be in this master
thesis indifferently used. This area of utilization is the most extended one in the world
of Skins and Themes and the majority of existing tools and examples of Skinning
make actually reference to it. For example, the Table 2.1.1 contained almost only
examples to this area of application. There are not default Skins or Themes for the
B2B-area, since the point of view that this B2B-relation will be always more specific
as the B2C relation, and the creation of common Skins/Themes and publication of
27
them on the Internet has no sense. As it was also already written (section 1.2), the
goal of using Skinning in these cases is to provide the applications with the attracting
feature, of allowing the end-users adapting the user-interface to their necessities and
liking.
The following figure (Figure 2.1.6) shows both areas of application in a schematic way:
Figure 2.1.6: Representation of B2B and B2C relations
A third possible area, which would make Skinning still more attractive for developers and SW
companies, is that the business customers could also modify the GUI of the applications that
they have bought to providers, and they would also be able to customize the GUIs for their
end-customers. It is actually a mixture of both areas (B2B/C when it is not the end-user
himself, who skins the application, but the business customers, who personalize the GUI for
the end-users). Therefore, it has not been added to the previous classification, since it
cannot be considered as a new area of application, but as a mixture of the other two.
2.1.7
Technique of Skinning
In this section, the main objective is to outline the answers to those questions, which were
already posed (List 2.1.1). I have called this section as the technique of Skinning, because it
will be here explained all that is till now understood with this word for the most skinnable
programs existing on the market. However, this does not mean, that what in the following
paragraphs is presented, must be the only way to achieve skinnability in an application.
28
Anyway, all these answers are very recommended to get a better idea of how the property of
Skinning could be implemented, since they phrase the most typical concepts that this
technique involves, especially in the “End-Customer” area of application.
2.1.7.1 What must be done to skin an application?
The process of Skinning in those skinnable programs involves always two different phases:

Installation of a new skin in the application: either a new skin is by the user manually
created or an existing one is downloaded from one of those web-sites about Skinning
in Internet

Choice of one of the installed Skins to be viewed in the application: it depends on the
kind of program, but the majority of them offer the possibility to do it from its menu of
properties, with an easy click on the selected skin
2.1.7.2 How can all these Skins and Themes be obtained?
The most common Skins/Themes are a set of bitmaps (.bmp) that represent the graphics to
be viewed in the layouts of skinnable applications. They are normally structured in wellorganised directories, whose hierarchy must be always kept.
There are three ways to obtain a Skin/Theme:

Download them from Internet

Create them manually: It depends quite a lot on the program. Nevertheless, the most
existing tutorials recommend their readers to download an existing Skin/Theme to
follow its structure. With an editor or a paint-program, it is possible to work on a copy
of the already existing skin and design a new one. There is always a structure of
directories, where the Skins are saved, and whose form must be always kept.
However, it is not so difficult to maintain this hierarchy, when an existing Skin is used
as pattern. The self-created Skins/Themes can be even uploaded to any place on the
web, so that other end-users of the program have the possibility of downloading and
installing them in their applications

Use a tool: Some tools make it easier to create Skins. Not only the paint-programs or
editors, which are necessary to do it, but other more advanced tools that make the
conversion from a bitmap to a Skin automatically. These examples are, at most,
specific for certain skinnable programs. For example SkinStudio is a tool to create
Skins for WindowsBlinds (Windows Skinning) automatically.
29
In many skinnable programs (Netscape, Mozilla, Winamp…) web standards are used (XML,
CSS…), and this is one of the things that allows Skins/Themes appearing and work
identically on any platform. This does not actually mean, that there is a standard work of
Skinning, but that some of these applications have adopted standard technologies to find
their own solutions in order to achieve Skinnability.
Sometimes, the files and directories that compound a Skin/Theme must be compressed
together with an executable file for its installation. Anyway, it will always depend a lot on the
specific program for which they are created.
2.1.7.3 How can they be installed?
Once the Skins/Themes are downloaded from Internet, they must be decompressed and
either there is an .exe (for example: Yahoo, Messenger, etc) or they allocate themselves
automatically below the directories of the certain program with the proper structure.
After the installation, any of the installed Skins can be chosen to be part of the actual layout
of the application. It is usual that these skinnable programs have in their menus some
properties that refer to the available Skins and Themes.
2.1.7.4 Which kind of programs must or could be used?
There are some specific programs or tools for each of those skinnable applications; for
example, there are tools that allow making the entire process, which means no effort for the
user to skin his/her application. Other kinds of programs that could be also needed in the
process of Skinning are for instance, de/compressors (WinZip…), editors (general or
destined to work with a certain program), photo/paint-programs (Photoshop…), etc, which do
not make the whole process but facilitate it.
2.1.7.5 Conclusion
Each of the previous questions (List 2.1.1) could be much better answered particularly for
each skinnable program. So it is, that all of them have their own Skinning tutorial. In those
already mentioned Skinning web sites, where all Skins and Themes are posted, there are
also plenty of links to different tutorials, which can be consulted online or downloaded.
See the links to find any specific tutorial (section 5.3.1, links [1.1] - [1.8]).
2.1.8
30
Advantages and disadvantages of Skinning
The following tables present the set of advantages (Table 2.1.2) and disadvantages (Table
2.1.3) of the use of Skinning. The difference between the two existing areas of application
(section 2.1.6) has been also here taken into account, because some of the features of one
area are not entirely applicable to the other one and vice versa. They have been grouped in
the same cell of the table only when the advantages or disadvantages and their respective
consequences were exactly the same for both areas of application.
App.
area
Advantages of the Use of Skinning
B2B  Differentiation: Skinning makes it possible to customize the applications for each customer,
from the point of view of the developer of the program. Any product can be effectively
branded and customized with a look and feel that separates it from the rest of the crowd. A
skin that uses for example, the company’s colors and logos, can be easily created. It must
be also taken into account that companies are increasingly relying on business software to
generate parts of their websites and intranets, supplying value-added access and
information to employees, customers and partners by linking their entire back-end system to
a web interface available from any computer connected to the Internet. For this reason, the
front-end must reflect the branding of the company whose data is being interacted with. All
this is happening increasing over the Internet and within corporate intranets; for this reason,
the visual design of software running in a web environment must respond accordingly.
Skinning methods make all this possible and in definitive they provide:
o
Customization (Branding, Corporate Identity, Configurations, Sub-functions) of
applications
B2C  Differentiation: Skinnable SW and applications are more attractive for the end-user, which
implies a reason to be chosen against the not-skinnable competitors. It allows:
o
Personalization (they can differentiate themselves from the rest of users, and
personalize their applications at run-time, which means a factor of attractiveness)
 Website “stickiness”: Apart from the high demand for customization features in today’s
programs, there is also another reason to allow the end-customers changing the skin on the
program: website stickiness. It is extremely easy for providers of these programs to build a
"skin community" by asking skin authors to create and upload skins to their site. As long as
their skin library will be evolving, their customers will continue to visit this site to check out
new skins. While they are there, developers can provide information on product releases and
so forth
31
B2C  Multiplicity of choice: The users have the possibility of choosing not only from a couple of
Skins/Themes, but from hundred of them. This implies a significant freedom for the end-user
to choose, which supports even more the ideas of attractiveness and differentiation already
mentioned before
 No cost: The fact that once an application has been made skinnable, it implies no cost more
for the end-user to change the Skins/Themes should be considered an advantage, because
the user must not concern him/herself about it. He/she must only know the way to skin
her/his application and no more. On the contrary, the words “no cost” cannot be applied to
every use case of Skinning. For example, the use of Skins and logos to be showed on the
displays of mobile telephones is by no means free.
Both  Text skinning: Possible to use the technique of Skinning not only to modify the layout
B2B
(logos, colors...) but also to change the language. This advantage is applicable to both areas
&
of use, because on the one hand the language might be also a possibility for the end-user to
B2C
choose when the same application is to be offered in different countries, and therefore the
necessity of different languages. On the other hand, big providers and developers
companies have mostly customers in different countries, which means they need to offer
diversity of languages. It allows, in short:
o
Internationalization (i18n) and Localization (l10n) of applications
 Easier presentation: According to the explained pattern (MVC, section 2.1.2) that is applied
in Skinning methods, the presentation of the layout should be simplified, since the point of
view, that the content management is separated from the presentation management
 For the developer: Easier modifications in the implemented code: Since Skinning requires
and uses the separation of content management from presentation management, it implies
also for developers and programmers, easier modifications of the application’s code. It is
actually derived from the separation of the view and the model in an application, which
means that it is not directly an advantage from Skinning, but an indirect one, because of the
requirements of its implementation.
Table 2.1.2: Advantages of the use of Skinning
App.
Area
B2B
32
Disadvantages of the Use of Skinning
• No standard skinning technique: There is neither a wide area of research, nor
standard work about it. For this reason, the skinning technique is not absolutely clear
for developers in each case, especially for this area (B2B) of use. Therefore, it implies:
o
“Time exposure” for the developer: Dedication of time to determinate how to do it,
and to choose the suitable method always before building the application code
o
“Complexity”: The development of applications may be more complicate, if
Skinning is used, and the extra task of separating the content from the view is
practically always necessary, which forces in some cases to use technologies that
may be not very familiar for developers
o
“More requirements” for systems: Applications become sometimes slower (for
example: use of Java Swing) or require more saving space
B2C
• No standards: Though the existence of a huge number of skinnable programs in this
area, there is even neither standard work, nor good documentation about how to do it,
which means that the creation of any new skinnable software will force the developer of
it, to implement him/herself a method manually, to offer Skinnability in his/her
application. It should be also here taken into account the recent existence of more and
more Skinning tools in the last three years, which make the process easier and easier.
However, there are still not enough tools to cover all use cases and when they are
used, it is often necessary to adapt them to the certain case of utilization
• Decrease of “expressiveness”: Skinnability reduces paradoxically the expressiveness
of the user interface. Only those objects that are supported by the existing Skins can
appear in the GUI. This disadvantage refers more to this B2C-area of application,
because it exists no offer of already created Skins/Themes for B2B-area. Another
example related to this disadvantage is, for instance, the change of the colors of the
GUI controls and other elements of an operating system (for example: Windows). The
users are not, however, given free reign to modify the colors arbitrarily. Some of these
predefined schemes are specially designed to support users with impaired vision
• Loss of “recognition”: Sometimes it is also interesting for programs or OS that they
are recognized. If the possibility of Skinning exists, they will not be any more identified
(they loose their own branding). Software developer-companies that decide to offer
Skinnability in their products must assume that their own “look and feel” will be lost.
Some companies find it damaging for its image and recognition and decide not allow it.
For example, Macintosh, incidentally, has become even more covetous of its brand
integrity and no longer allows users to apply predefined schemes to its GUI
Table 2.1.3: Disadvantages of the use of Skinning
2.1.9
33
Limitations of Skinning: Existing patents
In this section, the existing patents in the scope of Skinning are exposed.
First of all, it should be written that, the search has been done in IPAS-BUS web site, where
it is supposed that all existing patents in the world are registered.
IPAS-BUS stands for Intellectual Property Application System - Business Unit Services and
is a suite of tools, accessible over the Siemens intranet, so that the companies can back up
their corporate decisions with information obtainable from patent publications.
IPAS-BUS offers four different modules, each with a different focus:

First Publications: It informs about what the competitors are working on and what they
are registering. It gives also information about the newly granted patents

Siemens usable Patents: It includes all patens which are owned or licensed by
Siemens

End User searching: It gives the possibility of searching any patent registered in the
entire world

Direct Document Ordering: It allows searching for a certain patent and receiving it per
mail
After the search through IPAS-BUS site, only three patents related to Skinning topic have
been found (June 2003). From these three patents, only two treat actually totally with the
subject. Therefore, the newness of this topic is now even more obvious, since only two
registered patents have been found in the entire world. The lack of patents should be
considered also as an important advantage, because it implies an absence of limitations in
the scope of legal rights, when building a skinnable application. Almost everything is free and
anything can be freely used.
In the following, the patents are described:
2.1.9.1 Patent 1
“Skin user interface for windows media player, has XML skin model definition files for
defining model that allows user to change look of user interface”
AN:
PAT 2002-690547
…
PD:
01.08.2002
34
Description: It explains the method of organizing and providing the skin user interface and
exposes also the skinning method to skin the user interface of any SW application (PC) used
in any computer system. They use XML to describe the user interface, which means
flexibility, variety and functionality.
2.1.9.2 Patent 2
“Skin provision method for software application e.g. media player, involves synchronizing two
different properties of skin elements, such that change of one property causes change in
another property”
AN:
PAT 2002-682077
…
PD:
01.08.2002
Description: It provides two different properties of skin elements to facilitate the skinning of
user interfaces. It provides a robust, dynamic skin that can be rendered and re-rendered at
run time. Provides a robust degree of flexibility in creating custom skins that can be used by
original equipment manufacturers (OEMs), independent hardware vendors, and end users.
Provides improved skinning models, a rich user experience and skins that are unique in
appearance, function and layout.
2.1.9.3 Patent 3
“Advertisement media management method for on-line advertising involves targeting users
based on demographic information and user event logging “
AN:
PAT 2002-371741
…
PD:
28.02.2002
Description: This is not so interesting, but I have considered adding it here, because there is
a wide explanation of how this Skinning module has been built in the documentation of the
patent and maybe some readers could be interested in it.
2 Exposition of the technique of Skinning: Deployment of Skinning Methods
2.2
35
Deployment of Skinning Methods
In this section, the existing methods to create a skinnable application in the two possible
areas of use of Skinning are outlined and classified according to different criteria.
2.2.1
Skinning methods: Introduction
The question now, once that the general idea of the Skinning concept has been already
provided, is the “How to” of Skinning and that is precisely what this chapter describes.
Before starting with the classification and description of the methods, it is adequate to explain
the criteria that have been chosen to sort and describe them.
Firstly, it is convenient to notice that the two possible areas of use of Skinning (section 2.1.6)
are not considered separately in the classification. A unique list of methods is presented,
which is considered valid for both areas of application, and when necessary, different
references for each area are added. Besides, the design pattern MVC (see section 2.1.2),
which consists in separating the content from the presentation is here again referenced to
explain the role of the different technologies concerned in each method.
Some of the presented examples are widely extended and even used by very well known
applications, such as Winamp, Netscape, Mozilla, etc. As it will be seen, most of them
involve the use of web standards (XML, CSS, etc.), combined with the idea of separating the
content from the presentation (MVC) to make their goal possible. The functionality of some of
these skinnable programs is also described within the presentation of the methods, just after
the classification table. Nevertheless, some methods from the ones presented in the table,
are just different ways to achieve Skinnability in different environments of work, and are not
used in a so extended way as the others. Their small scope of utilization is again due to the
lack of research and standard work about this topic.
2.2.2
Skinning methods: Classification and description
According to the criteria exposed in the previous section (2.2.1), the following table shows
some methods to build skinnable applications. It will be also indicated which of them make
use of Industry standards, which of them need a certain framework or any other
requirements for their function, as well as the scope of application of every of them.
1
View
XML
2.2.2.1
2
Controller
HTML
Java
+
Servlet
√
Area of
application
Model
Use of
Industry
Standards
Method
Technical Characteristics
B2B
and
Features
- Web applications
- Java platform
No
- Web applications
- Use of CSS
No
(Any skinnable site for B2C
(only HTML is
or B2B area of application)
not possible)
application)
CSS
Scripting
Language
2.2.2.2
(Examples)
Requirements
(Only for the B2B-area of
CSS
(X)HTML
Scope of application
Conditions
Framework
MVC
Pattern Reference
36
√
B2B
B2C
- Browser with
- SW on PC (Browsers
such as Mozilla, Netscape)
CSS support
- Script engine
(for redirecting)
3
XML
XSL
XSLT
2.2.2.3
√
B2B
B2C
- Web applications
- XSLT as
controller
No
or B2B area of app.)
- SW on PC (Winamp…)
4
XML
CSS
ASP.NET
2.2.2.4
√
B2B
B2C
- Web applications
- CSS (only
HTML is not
possible)
.NET
- Difficult to code
a server control
- .NET
5
CGI
XSL
XSLT
2.2.2.5
√
B2B
B2C
- Web applications
- A small
executable script
must be build
No
- A logic module
as data model
must be build
6
2.2.2.6
7
2.2.2.7
Skinning with the
No
B2B
skinnable classes of
- Java platform
No
No
can be programmed: web
Java Swing
Skinning with the
- With Java Swing, any app
No
B2C
applications & SW on PC
B2B
- It is a way to code a
- Java platform
dynamic GUI with java for
- Browser that
any java application (SW
supports at least
on PC or web application)
JDK 1.1
AWT classes of Java
B2C
Table 2.2.1: Classification of skinning methods
37
Another point to keep in mind in relation to the Skinning methods is that their function can be
divided in two different tasks:

Creation and definition of a new Skin, that is: Design

Substitution of a certain Skin for another: Functionality
It is interesting to write here that Skinning could be also implemented in many other ways.
For example, those skinnable applications, where the property of Skinnability is integrated in
them (see section 2.1.7), have their own solutions, but from most of them it is difficult to find
out something useful, because they only provide documentation about “how to skin them”,
but not the way they use to become skinnable.
Anyway, the methods that the reader may need to skin any application have been exposed in
the previous table (Table 2.2.1) and will be described in full detail in the following sections.
The advantages and disadvantages of the methods have been grouped and will be
presented in Table 2.2.2 in subchapter 2.2.3.
2.2.2.1 Method 1: Skinning method for java coded web applications
2.2.2.1.1 Description

MVC: Data Model: XML, View: HTML + CSS, Controller: Java servlet

Model: XML files that act as properties files and contain every customizable element
(logos, text style, paths of other files, language, etc.) of the GUI of the application

View: HTML template that will be skinned with the values that are contained in the
XML file and CSS to define the style of the different elements in the HTML site

Controller: Java servlet. There must be a link between the content (Model) and the
layout (View). The control can be implemented with any programming language.
Here is presented java because it is actually a particular method, destined to java
implemented web applications
The next figure (Figure 2.2.1) shows the interworking of all participants in the solution.
This method will be applied in the practice, when skinning an existing web application.
Therefore, it will be here not further described. See section 3.3 for more information
about it (description, appliance, advantages, disadvantages…).
38
Figure 2.2.1: Representation of skinning method 1 (XML + HTML/CSS + Java servlet)
2.2.2.2 Method 2: Skinning method for web sites to be skinned by end-users

MVC: Data Model: (X)HTML, View: CSS, Controller: Scripting language

Model: With normal tags of (X)HTML the site can be created

View: A new Skin implies a new CSS. Each CSS contains some code unique to
each Skin and the rest are standard classes that appear in the style sheets of every
Skins

Controller: Scripting language. There must be a link between the content (Model)
and the layout (View). The control can be implemented with any scripting language
(php, asp, javascript):
o
php/asp + css: the basic of this whole system is a script-page that redirects to
the correct style sheet based on a cookie (all existing CSS-pages point at it);
the use of cookies (see below) is only needed in B2C uses of case. A script
that allows people to set their preference of Skins is also necessary if the user
will be allowed to modify the layout (B2C).
The next picture (Figure 2.2.2) shows the flow diagram between the client and the server
when using this method.
39
Figure 2.2.2: Flow diagram of skinning method 2 (php/asp with CSS)
o
JavaScript + CSS: JavaScript acts similar to php/asp to identify a desired
Skin and to switch to it dynamically. For B2C uses of case, it is obviously also
needed to read and write cookies, so that the selected item can be stored.
The solution to dynamically import a style sheet can not be done only with
JavaScript but also with the help of the following method:
“document.writeln(‘<link href= “’+SKINS_PATH’.css” type= “text/css”
rel=”stylesheet”>’)”.
The idea is just write into the document while it is being loaded, a browser will
parse this like any other content and load the defined style sheet file, which is
applied to the document. To give the users the possibility of choosing between
different styles, a reusable function is used. This function receives the name
of a Skin as an argument. To call it:
<a href="javascript:setTheme('default')">Default Theme</a>

Cookies: If this method is used to create a skinnable web site, whose layout can be
modified dynamically by the end-user (B2C), the use of cookies is necessary. They
maintain the status of the user and save the new skin when the old one is replaced.
They store the last choice for a Skin of the end-user. It would not be needed if the
one that modifies the layout were the developer of the application (B2B). Moreover,
40
in a B2B area of application, business customers are always against its use,
because of the security and privacy of personal data.
2.2.2.2.2 Example of Mozilla: “Skinning a browser”:

Mozilla is an example of those skinning applications that make use of web standard
technologies and it fits perfectly with this second presented method

The concept of separating the content from the view has been here also taken into
account.
o
o
MVC: Data Model: XUL/DOM, View: CSS, Controller: JavaScript / XPCOM
•
XUL/DOM: Structure
•
JavaScript/XPCOM: Behaviour
•
CSS + Images: Skin
XUL: XML-based User-interface Language. It was created for Mozilla and it
defines its user interface. See in section 5.3.1, reference [3.3], the XUL tutorial
o
DOM: Document Object Model for XML files. It is a programming interface for
XML documents and defines the way an XML document can be accessed and
manipulated
o
XPCOM: Cross Platform Component Object Model. It is a framework for
writing cross-platform, modular software. As an application, XPCOM uses a
set of core XPCOM libraries to selectively load and manipulate XPCOM
components. These components can be written in C, C++, and JavaScript,
and they can be used from C, C++, and JavaScript with extensions for Perl
and Python that are under development
o
CSS files are applied to the XUL interface by means of special import
statements, processing instructions and the special hierarchy

Advantages and disadvantages of the method that Mozilla uses to skin:
o
Advantages: XUL and CSS provide real UI development tools that are
genuinely cross-platforms and that anyone can use. In the very near future, it
will be possible to skin XUL files dynamically and completely (by pressing a
button, selecting a skin from a menu, or by accepting a skin from over the
web). Skins will be than defined in a global skin file and it will be possible to
apply this file to the whole application (like the Mozilla browser), so that all the
various windows and parts will look consistent.
o
41
Disadvantages: It is still necessary a manual interaction and a bit
knowledge of XML is needed to learn XUL; the use of CSS is also required
and they may be cause problems with some browsers

See more information about Skinning Mozilla in section 5.3.1, reference [2.7]
2.2.2.3 Method 3: Skinning method with the use of XML technologies

MVC: Data Model: XML, View: XSL, Controller: XSLT

Model: All data are put in a XML file and they can be transformed into completely
different layouts using XSLT

View: A new Skin implies that a few XSL files must be created for the Skin and
uploaded to the server

Controller: XSLT makes the junction between the Model and View. See Figure 2.2.3
to view the graphical representation of the interworking between these technologies
2.2.2.3.2 Example of tool that uses this technology:

xReporter is an open-source, web-based database-reporting framework. It allows
you to create flexible reports without any programming. The reporting server outputs
a XML file, which will be transformed with the use of XSLT into the HTML code that
forms the layout of the site. Basically, adjusting the look of the site is thus a matter of
editing the XSLT style sheets. However, to avoid having problems with the style
sheets, there's a skinning system available. (See link [5.20] in section 5.3.1 for more
information)
Figure 2.2.3: Transformation of XSL files in (X)HTML to be viewed in a browser
42
2.2.2.3.3 Example of XML with ASP.NET Framework:

The web-skinning engine in ASP.NET defines a number of special tags that
represent dynamic content to be pulled in at run time. These special tags are defined
as part of the “urn:schemas-DevHawk-net:webskinui” namespace, which is mapped
by convention to the skin namespace prefix. These tags allow the engine to find
content exposed by SQL 2000 for XML queries, business objects, and intrinsic HTTP
request data collections (forms, query strings, and so on)

Once all WebSkin [tool 6.1.2] nodes have been processed, an XSLT Skin must be
applied before sending the content to the browser. The transform tag can specify the
XSLT either statically or dynamically. If the transform tag specifies a:
o
Default attribute: XSLT file is than statically chosen to skin the XML content
o
Variable and method name: the handler calls than the specified method of the
variable to determine the XSLT skin file to use

See the article: “Rich XML Classes Let Users Personalize their Visual Experience on
your ASP.NET Site” in the references (section 5.3.1, reference [2.9]) for more
information about it.
2.2.2.3.4 Example “Skinning a MP-3 player” (Winamp, Trillian):

Winamp and Trillian, for instance, are other examples of those skinnable programs
(B2C), that use XML to skin their GUI, but in a bit different way

How does Winamp use XML?
o
It is fully implemented in XML: from the skinning files to the playlist
o
The use of XML here is, however, to give form to each skin. The separation of
Model-View-Controller is not so well defined

o
See tutorial of skinning Winamp for more information (section 5.3.1, link [2.8])
o
Trillian utilizes the same method: it is there called SkinXML technology
Advantages and disadvantages of the method used by Winamp:
o
Advantages: It is easy to add new Skins for end-users. They have freedom to
create their own Skins or download them from Internet. All advantages
mentioned for Skinning in B2C area (see 2.1.8) are also here applicable
o
43
Disadvantages: A bit of knowledge in XML is needed to create a new Skin by
the end-user, which could imply a bit effort for them and be the cause of
refusing it.
2.2.2.4 Method 4: Skinning method for ASP.NET web applications

MVC: Data Model: XML, View: CSS, Controller: server controls of ASP.NET (it helps
to separate the content from logic)

Model: An XML file organizes the information and passes it to the control. It can help
to add, update and delete skins without modifying any pages or shutting down the
application. See the code in Figure 2.2.4

View: A Skin is a CSS file, where styles are defined for various HTML files and CSS
classes. It can optionally include a JavaScript file, which is associated with a page by
a script element in the head section of the page. Another optional component of a
Skin is a subdirectory where graphic files restored

Controller: Layer of abstraction: server controls render HTML text at runtime,
therefore HTML text has not to be worked directly any more. The application of a
Skin to a page is achieved by placing a link element in the head section of the page:
<link rel="styleSheet" href="[styleSheetFile]">
<?xml version="1.0" encoding="utf-8" ?>
<skins>
<skin name="red" styleFile="styles/red.css" scriptFile="scripts/red.js
imageFilePath="images/red"/>
<skin name="green" styleFile="styles/green.css" scriptFile="scripts/green.js"
imageFilePath="images/green"/>
<skin name="blue" styleFile="styles/blue.css" scriptFile="scripts/blue.js"
imageFilePath="images/blue"/>
</skins>
Figure 2.2.4: Example of XML file that makes references to the existing skins

To create a new skin, it is necessary to:
o
Create a CSS file
o
Create a script file
o
Create a subdirectory to store skin-specific graphic files
o

Add a new XML element to the XML file
Delete a skin is even more easy:
o

44
Delete the corresponding XML element from the file
What does the Server Control?
o
It needs the location of the XML file
o
When the Skin to be applied is chosen, the control reads the Skin file and
finds the full paths of the CSS and script files specific to the current Skin
o
It renders them in the link and script HTML elements
o
It finds also the path of the directory that stores graphic files specific to the
current skin and make the path available as a property, whose value can be
used by the page developers to specify the source attribute of image
elements

It must be here noticed that the basis of this method is very similar to the first
presented method (see 2.2.2.1), but with the difference that now the framework
ASP.NET has been used, with its respective advantages and disadvantages (see
2.2.3)
2.2.2.5 Method 5: Skinning method for web applications based on XML and CGI

MVC: data Model: CGI (logic module), View: XSL, Controller: XSLT

This example is only exposed to see that XML could be used with other technologies
such as CGI, but the way Skinning will be achieved is actually the same as the
already presented with XML (method 2.2.2.3)

This presented method is actually an implemented application that provides a
modular, XML-based alternative to traditional CGI scripting

It consists of four parts:
o
A small executable script that provides access to the application
o
Model: A logic module that implements various handler methods that are
called in response to the current state of the application
o
View: What the logic module returns should be XSL files, which are
transformed with any XSLT processor
o
45
Controller: One or more XSLT style sheets that are used, based on
application-state, to transform the data returned by the module (XSL) into
something that a browser can display to its users
2.2.2.6 Method 6: Skinning method with the skinnable classes of Java Swing

This method consists on the use of the well-known programming language: Java
Swing. It allows building skinnable applications because it has classes, whose
functionality is precisely to add the property of skinnability to all those applications
programmed with java swing.

It is a bit different from the ones presented before but very interesting since the point
of view, that it adapts itself perfectly to the pattern of Model-View-Controller. It is
actually one of the most known cases of application of this MVC-model.

The way the MVC-model is used in java swing is a bit different: while the MVC
design pattern is typically used for constructing entire user interfaces, the designers
of the Java Foundation Classes (JFC) used it as the basis for each individual Swing
user interface component. Each component (whether a table, button, or scrollbar)
has a model, a view, and a controller. Furthermore, the model, view, and controller
pieces can be changed, even while the component is in use. The result is a user
interface toolkit of almost unmatched flexibility.

See in references (subchapter 5.3.1, link [7.10]) for more information about MVC with
java swing
2.2.2.7 Method 7: Skinning method with the AWT classes of Java

It is a method to code a customizable interface. It is actually an example of how to
code a skinnable application with the set of awt classes of java. The example here
presented is for an absolute basic user interface. The following points are needed:
o
A new layout manager (SkinLayout)
o
A properties file that contains information about how the interface is laid out
o
An ImageLabel (lightweight) component for no interactive areas of the screen
o
An ImageButton (lightweight) component for interactive areas of the screen
o

46
Other lightweight components, if the application need them
See in references (section 5.3.1 link [8.1]) for more information about how it should
be coded. Points to consider:
o
Class Utils: to load images
o
ImageLabel and ImageButton are implemented
o
SkinLayout: it can be constructed with two methods, but always specifying
the location of the properties file (input stream or filename)
o
Properties file: it must include all the
elements that are present on the
layout and their properties (size,
position,
etc).
In
the
following
example, the properties file of a
button is presented. The attributes
here show the image, the pressed
image and the focused image of the
width=230
height=42
back.width=50
back.height=40
back.xpos=0
back.ypos=0
back.visible=true
back.attributes=image=back1_nf.gif
,imagepress=back1_press.gif,
imagefocus=back1_f.gif
button.
Figure 2.2.5: Example of properties
file in java skin method
(source: section 5.3.1 link [8.1])

In the following figure, an example of an applet coded with this method is showed. If
the Button Layout 1 is pressed the first layout can be seen (Figure 2.2.6) and when
the button Layout 2 is pressed, the other layout is shown (Figure 2.2.7):
Figure 2.2.6: Layout 1 (Java Skins)
Figure 2.2.7: Layout 2 (Java Skins)
(source of pictures: section 5.3.1 link [8.1])

At the moment, the custom attributes that can be set for AWT components, when
using SkinLayout are fairly limited. For example, the layoutContainer() method of
SkinLayout() requires that a set of methods in a component have a single string as a
parameter. That means that an attribute such as background = #FF00FF
(background color of a component) will not work successfully on an AWT component
47
(unless it is subclassed to provide a setBackground (String color) method).
Alternative to the previous problem:
o
Altering the tagging structure slightly, the layout manager could construct an
object (for example, color) from the hex color code, and pass that into the set
method. SkinLayout could also be extended to handle specific set cases
(setFont(), setBackground())
o
Another alternative: use of XML to define the user interface, which could
provide enormous opportunities for extending the capabilities of the layout
manager. That is: use a packaging structure for the skins (such as Winamp
does). The layout property could be zipped up, along with the images it needs
to implement the interface. SkinLayout should then be able to unzip the
package to retrieve properties and images

AWT requires sometimes many panels to implement a relatively simple design
(unless a GridBagLayout is used, which adds an additional level of complexity)

Comparing to Swing: Java Swing can be a very slow download; it can, however,
provide a larger palette of components than AWT
2.2.3
Advantages/Disadvantages of the methods
Once all methods have been described, the advantages and disadvantages of them will be
presented in the following table (Table 2.2.2).
I have decided to show them all together in one table, because most of them have common
components or technologies and therefore they coincide with some characteristics. So it is,
that those advantages or disadvantages that are consequence of the use of a certain
technology, will be the same in all methods that utilize the technology.
The list of advantages and disadvantages is presented on the left side of the table and on the
right the methods related to each of them are referenced.
Advantages
48
Methods
- Only cross-platform web standards, instead of proprietary toolkits or Methods: 2.2.2.1,
languages, are used to create the Skins or in the process of Skinning
2.2.2.2, 2.2.2.3,
2.2.2.5
- Well-known programs (browsers, mp-3 players, etc) use the same Methods: 2.2.2.2,
methods to skin the application. It is an advantage because that 2.2.2.3
means that there is a lot of information about it and that the method
works properly
- If .NET Framework is part of the solution, there is always a deep Methods: 2.2.2.4
support behind it. For example:

XML and XSLT have support in the Microsoft .NET
Framework Base Class Library

The down-level rendering capability of ASP.NET server
controls (method 2.2.2.4) is a great advantage for those
browsers that do not support the CSS because it is not
necessary to write any line of code more

Use of tools created to work with .NET. There are plenty of
tools for .NET platform (see section 2.3.3)
- If a programming language with skinnable classes is used, the Methods: 2.2.2.6
process is much easier
Disadvantages
Methods
- Use of CSS implies that the browser must support them; the more Methods: 2.2.2.1,
dependence the GUI has on the CSS, the more problems will be with 2.2.2.2, 2.2.2.4
different browsers
- If a framework, such as .NET is used, the whole application is Methods: 2.2.2.4
bound to it and there is no freedom to use any other framework
- Slowness of Java Swing; many browsers do not support it
Methods: 2.2.2.6
- Limitation of awt compared to Swing
Methods: 2.2.2.7
- Cookies are not well considered, though they must not be used if Methods: 2.2.2.2
the application is not thought to be personalized by the end-user
- A previous differentiation of content and design must be done and it Methods: 2.2.2.1,
could be a tedious task. It is actually a requirement for all skinning 2.2.2.2, 2.2.2.3,
methods but for the ones cited on the right, it implies more time
2.2.2.4, 2.2.2.7
Table 2.2.2: Advantages and disadvantages of the skinning methods
2 Exposition of the technique of Skinning: Deployment of Skinning Tools
2.3
49
Deployment of Skinning Tools
As the previous chapter (2.2) has shown, there is a set of different methods in the ambit of
Skinning. They allow integrating manually the feature of Skinnability in some applications. In
this chapter, the most interesting products and tools, in relation to Skinning, will be
presented, and grouped according to different criteria. A more detailed description of each of
them can be also found in the appendix (section 6.1).
2.3.1
Skinning tools: Introduction
What is till now written in the master thesis is that Skinning is a very recent topic and that not
many research works have been done about it. Therefore, everything points that the number
of existing tools should be very reduced and limited; it is actually so. The number of tools
here presented is not superior to 15. However, it must be taken into account that this number
is supposed to be increased in the following years, because firstly, Skinning is an up-to-date
technique still in development, and secondly, SW companies have already realized the
importance that Skinning may have for the end-user and also for the customization of their
applications.
My first idea was to make a classification of the existing tools according to different criteria,
but after my research about the topic, I realized that it would not be worth. The main reason
of not having made a classification is that the number of tools that have similar features and
characteristics is not big enough so that they could be classified according to the same
criteria.
Although the classification could not be done, it is interesting to show some of the possible
alternatives to classify the skinning tools. It could be even useful for future research works,
when the market of skinning products had grown up.
Before presenting the alternatives in the next section (2.3.2), the following question will be
answered: What should be understood with the words “Skinning tool”? In principle, any
software program that makes it possible to skin a certain application could be considered as
a Skinning tool. On the contrary, not all tools here presented have the same functionality and
area of application.
2.3.2
Possible alternatives to classify the skinning tools
As it was already written, the alternatives to classify the skinning tools are here presented,
although the classification will not be done, due to the lack of common characteristics
50
between the different tools. There are not so many, so that the possibility of choice exists
when some of the conditions in the application to skin are already fixed, such as the
framework, programming language, functionality, etc. That is, there are not many tools that
have the same function or work in the same area of application, under the same framework,
so that a comparison or classification of them can be done.
In any case, the alternatives are presented in the next subchapters.
2.3.2.1 Alternative 1 for a classification: General or specific for a program
Two kinds of tools can be differentiated: those tools created for a specific program, which
correspond usually to the “Customer-area” of application and those that can be applied to
any implemented SW and utilized to skin any new coded application.
2.3.2.2 Alternative 2 for a classification: Functionality
As it was already mentioned, the process of Skinning involves two tasks:

Create a new Skin (Design)

Switch dynamically from the old Skin to the new one in runtime (Functionality)
Therefore, it is here necessary to make a difference between those tools that make it easier
to create a new Skin or Theme, and those that make it possible to replace dynamically one
Skin by another. A third type of tool would be naturally the one that integrates both functions.
2.3.2.3 Alternative 3 for a classification: Operating system or framework
A third alternative would be a classification according to the operating system for which they
have been created or the framework with which they can work properly. In the following
section, some tables will show the different existing skinning tools, and one of the
characteristic to separate the tools in different tables will be precisely the dependence or not
on a certain framework or operating system. As it will be seen, there are many tools created
exclusively for Microsoft (see Table 2.3.1) and are totally dependent on it.
2.3.2.4 Alternative 4 for a classification: Programming language
This fourth group attend to the programming language for which the tools are suitable. All
these tools could be also added to the group of which have not been created for a certain
skinnable program, but for general applications (see alternative 2.3.2.1).
51
In the following section, where the tables of tools are presented, there are some dedicated to
different programming languages (see Table 2.3.2 for C++/Delphi, Table 2.3.3 for Java, and
Table 2.3.4 for Visual Basic).
2.3.2.5 Alternative 5 for a classification: Proprietary or standalone tools
A significant criterion is also the fact of being proprietary or standalone tools; however, all of
the found ones are by chance, proprietary tools. There are no standalone programs and that
fits actually to the lack of standards in the world of Skins and Themes, as it has been more
than once written in this master thesis. It could be however, a good alternative for future
works of research.
2.3.2.6 Alternative 6 for a classification: Areas of application of Skinning
This feature (section 2.1.6 to see the areas of application) will be taken into account when
presenting the tables of tools; many of them work in the B2B area of application, and have
the functionality of allowing the developer to create customizable applications. The fact that
not so many tools are designed to work in the B2C-area of application is because the most
skinnable existing programs (MP-3 players, browsers, etc) pertain to this area (B2C), but do
not need any tool, since they have internally the way to offer skinnability for the end-user.
Only tools that help to create new Skins (design) may be created for these skinnable
programs because they have already a skinning module that makes the rest.
2.3.2.7 Alternative 7 for a classification: Appliance of MVC model
The appliance of the separation between content and presentation in the function of the tools
is also an alternative to classification. In the description (section 6.1) of tools it will be
graphically presented the model for all those tools that make use of it and in the tables, it will
be also a characteristic to take into account.
2.3.3
Skinning tools: Overview
In this section, the existing skinning tools and frameworks are presented in different tables.
No classification has been done, but a division of them in different tables according to some
of the common characteristics, which are:

Platform or Operating System dependent tools (Table 2.3.1): Microsoft

Not dependent on Platform tools: Programming language C++/Delphi (Table 2.3.2)

Not dependent on Platform tools: Programming language C++/Delphi (Table 2.3.3)

Not dependent on Platform tools: Programming language Visual Basic (Table 2.3.4)

Rest of tools (Table 2.3.5)
Tool or
Framework
6.1.2.1
WebSkin
Area of
Kind of Tool/Framework
Programming
(Functionality)
Languages
App.
B2B and
B2C
Skinning of ASP.NET
C/C++
Platform
Price
52
MVC
Requirements
License
ASP.NET
sites tool
FREE (noncommercial) to
MICROSOFT
Yes
(ASP.NET)
>1000$
ActiveX control tool that
Visual Basic
Windows
FREE
Active
allows the developers to
5-6, Borland
95/98/
100$
Skin
dynamically change many
Delphi 3-6,
Me/NT/
(Vs. 4.25)
components of the visual
Microsoft
appearance of their apps.
Visual C++5-
6.1.2.2
B2B
to <
MICROSOFT
No
2000/XP
6
6.1.2.3
B2B
Skinboxer
6.1.2.4
B2B
EZSkin
Windows
Complements ActiveSkin
Microsoft
providing more facilities,
Visual Basic
95/98/
(1 license)
such as Skinning also the
5-6, Borland
Me/NT/
to < 500$
MessageBox, Open/Save
Delphi
dialogs, Browse for folder,
Microsoft
ChooseFont,
VisualC++ 5-
FindText,
ReplaceText
6
Open source framework
C++
3-6,
2000/XP
Any
< 100$
MICROSOFT
No
(unlimited)
FREE
to build skinnable app. in
MICROSOFT
No
C++
6.1.2.5
B2B
ExSkin
ActiveX
control
that
enables the developers to
C++, ATL,
STL
Windows
98, NT
change the GUI of their
4.0,
projects, providing them
2000,
with the Skin (or look &
ME
feel) support; it contains a
Builder component that
>140.00 EUR
(download
MICROSOFT
No
only)
To
> 2000EUR
(unlimited
developers)
helps you to create Skins
6.1.2.6
B2B
DirectSkin
Skinning
tool
program:
it
for
any
COM objects
Win98,
From < 1000$
(Delphi, VC,
WinMe,
To > 8000 $
change the appearance of
C++, VB,
Win2K,
STARDOCK
any application and some
etc)
WinXP
PRODUCTS
allows
to
functions can be even
added
(technology
WindowsBlinds
in
MICROSOFT
No
(excluding
of
Terminal
any
Server)
program)
6.1.2.7
B2C
It is a suite of desktop
No
Win98,
MICROSOFT
< $100 + s/h
Object
tools to customize a lot
(Created for
Desktop
of aspects of Windows
a certain
WinNT,
STARDOCK
(Package of tools)
skinnable
Win2000,
PRODUCTS
application)
6.1.2.8
B2C
Package
of
tools
that
No
WinMe,
No
WinXP
Win98,
From FREE to
< 100$
MICROSOFT
Win
customize Windows and
(Created for
WinMe,
Customize
pertain to WinCustomize
a certain
WinNT,
STARDOCK
skinnable
Win2000,
PRODUCTS
application)
No
WinXP
Table 2.3.1: Overview of skinning tools that depend on Microsoft
Tool or
Area of
Framework
App.
6.1.3.1
B2B
Skinux
Kind of Tool/Framework
Programming
(Functionality)
Languages
Developing/Consulting
Firm
that
product
adapts
GUIs
to
Platform
Price
Any
Unknown
53
MVC
Requirements
License
C++
the
GUIs with
Yes
C/C++
No
No
the
aesthetic preferences of
the specific customers
6.1.3.2
skinning
Delphi 4,5,6,7
Skin
B2B
Tool
capabilities to Delphi &
to
add
& C++ Builder
Any
Commercial
< 100 USD
Factory
C++ Builder applications
4, 5
use license
Table 2.3.2: Overview of platform independent skinning tools (C++/Delphi)
Tool or
Area of
Kind of
Programming
Framework
App.
Tool/Framework
Languages
Platform
Price
MVC
Requirements
License
(Functionality)
6.1.4.1
B2B
ActionServlet
6.1.4.2
Open source web
Java
Any
FREE
B2B
SkinLF
Skin any Java
Java support
Yes
application framework
Java Swing
Any
application; a total
Free to use
and
customization
Browser with at
No
distribute
least JRE 1.2.2
support
framework for Swing
6.1.4.3
B2B
Pajes
Open Source Servlet
Presentation
Implemented
Any
FREE
Java support
Yes
in Java
Framework to create
skinnable web app.
separating HTML from
java code
Table 2.3.3: Overview of platform independent skinning tools (Java)
Tool or
Framework
6.1.5.1
Area
Kind of
Programming
Languages
of
Tool/Framework
App.
(Functionality)
B2B
Component to skin the
NeoCaption
non -client area (menu,
Component
border,
titlebar,
Visual Basic
Platform
Price
MVC
Requirements
License
Any
FREE to
download
No
No
menu,
control box and buttons)
of a VB project adding it
to a project
Table 2.3.4: Overview of platform independent skinning tools (Visual Basic)
Tool or
Framework
6.1.6.1
Area
Kind of
Programming
Languages
of
Tool/Framework
App.
(Functionality)
B2B
Platform
Price
MVC
54
Requirements
License
No
Any that SAP
SAP, which is able
(Created for a
supports (also
Portal (specific for it)
Editor
to skin the web
certain app.)
any browser that
Use CSS: problems
SAP supports)
with browsers
portal of SAP
Unknown
Yes
Editor created by
SAP
Bound
to
mySAP
Table 2.3.5: Overview of other tools (application dependent)
Each tool in the previous tables has a direct link to its detailed description in the appendix
(chapter 6). I must write here, that not all features were tested with the tools, but only the
most important. The subchapters of the appendix outline the functionality and add a couple
of important features of each tool, but not much more could be taken out from the
documentation in Internet or from the own experience. I have tried to expose here all existing
tools in relation to Skinning so that the reader becomes an idea of what can be found on the
market in the actuality. It was not an objective from the master thesis to test and use all these
tools, firstly because none of them was suitable for the Industry Example presented in the
practice, and secondly there was not so interesting in comparison to other parts of the
master thesis. Anyway, every reader will become with the subchapters in appendix enough
information about the tools that could be needed to skin an application and choose one of
them if any suits to the necessities, according to the characteristics the application. So it is,
after the choice more information can be read in Internet (all links will be given) or contacting
directly with the provider.
2 Exposition of the technique of Skinning: Typical boundary conditions
2.4
55
Typical boundary conditions (performance, security)
In this section the existing limitations of the technique of Skinning are outlined. It was already
mentioned the lack of existing patents (section 2.1.9), which in other case could have been
an intellectual property right limitation in the implementation of skinnable applications.
In this section, it will be written more about the implications that Skinning has in the
performance and security of all those skinnable programs and skinning methods, that have
been described in the master thesis.
Firstly, as it was cited in the description of the disadvantages of Skinning (section 2.1.8), the
fact that the use of this technique could reduce the expressiveness of the GUI is one of the
boundary conditions to consider. The reason is that not every Skins/Themes can be utilizable
in a certain layout. Skins are designed for a specific program and sometimes they are even
implemented for a certain version of the program and are not more valid to be used with
other versions of it. The end-customers have oft run into this problem, when they have tried
to install any Skin in a different version of the program for which it was created.
Secondly, it should be here considered if the property of being skinnable in an application
could affect the security, the performance, the slowness, and other possible limitations.
In principle, as it was already said, the fact of adding skinnability in an application could imply
a waste of time since the point of view that there are no standards and a way to make it
possible must be still thought by the programmer of the application. On the other site, once
that it is implemented, the skinnability does not affect the performance, neither the security of
the application. It must be only considered the method to be used: for instance, when Java
Swing is utilized, the application is much slower. However, it is slower not because of the
skinnability, but because of the programming language. Java Swing is itself very slow and
that should be considered before deciding to use it.
In conclusion, there are not many limitations in the world of Skinning methods, which implies
another significant reason to consider it only as a good quality in a program and even
another advantage of Skinning to take into account.
3 Evaluation and appliance of Skinning at an existing : Introduction
56
3 Evaluation and appliance of Skinning at an existing Web Server
Outline: This chapter constitutes the second main block of the master thesis. Some of the
theoretical research about Skinning will be put into practice in this chapter.
3.1
Introduction
The objectives and expected results related to the practice were also mentioned in the
beginning of the thesis (see section 1.4). It will be here exposed an Industry Example, where
the technique of Skinning has been applied. In the theoretical study, the Skinning issue has
been handled in all its sphere of activity and areas of utilization. However, the practical work
will only look at the appliance of Skinning in the world of the web applications and
particularized for the “Provider-Area” of application (see section 2.1.6).
I would like to mention firstly the problem to be solved in this introduction. I make here a very
brief description of it, in a couple of sentences, because I think it will help the reader to have
always in mind, what is supposed to be done:
Problem description: Siemens has some new web applications to be offered to a large
number of customers, which could be located in any place of the world. These clients want to
have the web applications they buy, with a customized and internationalized GUI, so that
they can read in their language and maintain their Corporate Identity, when they offer this
Web Services to their own customers. The actual existing solution (see section 3.2.5) for
customization of them could be too tedious when the number of clients is too high, and
therefore, it has been thought about using a technique/tool to achieve it faster an easier.
The objective now is to find the way to solve the problem as easy and quickly as possible.
According to what was presented in this document, the use of Skinning could be a very good
solution to this matter, and that is precisely what is going to be done in the practical part of
the master thesis: “Applying the technique of Skinning to achieve the Customization,
Personalization and Internationalization of a specific Web Application”.
3 Evaluation and appliance of Skinning at an existing : Introduction
57
The aim of the whole practice does not only consist in customizing the specific web
application of Siemens, but also in proposing a general method and demonstrating its validity
for any other one.
Once an overview of the problem has been written, I present in the following paragraphs the
way the rest of sections of this chapter will be organised.
First of all, in order to give a better idea of the work environment for the practical work, I will
describe the Web Service that has been chosen from one of those web applications that
Siemens offers in its new products (SURPASS products), and where the skinning technique
has been applied (see section 3.2).
Secondly, the proposed solution will be presented in full detail (see section 3.3), with all its
characteristics, advantages and disadvantages, together with all the experiences and
difficulties that I had during the practical work.
Finally, the last section (see 3.4) is dedicated to depict the advantages and disadvantages,
the possibilities and limitations of the proposed method, but not for the web application where
it was particularly tested, but for any existing web application, together with an evaluation
and conclusion of the whole obtained results from the praxis and tests on the server.
3 Evaluation and appliance of Skinning at an existing : Free-Call-Button
3.2
58
Free-Call-Button: Description of the web application
This section includes a description of the functionality of the Web Application to work with,
which is called “Free-Call-Button” and offer its end-users the possibility of being called free of
charge and get information about what they need.
3.2.1
Description of the work environment
Before starting with the detailed description of the Web Application, a graphical exposition of
the interworking between providers and customers in the particular case of Free-Call-Button
is shown in the next picture (see Figure 3.2.1):
Figure 3.2.1: Areas of Application particularized for Free Call Button Web Application
As the figure shows, Siemens will sell its Services to different customers (TELCO in Figure
3.2.1), who in turn, offer these services to all their subscribed clients (Call-Centers) and the
end-users will be able to make use of the service and be called free of charge by the
respective Call-Centers. It will be also explained where the customization of the application
must take place.
59
Siemens must offer customized and internationalized software to its customers. That is the
first B2B relation presented in the whole system and it is an example of “Provider Area” of
application of Skinning.
Moreover, the customers of Siemens have to customize the service for each of its customers
(Call-Centers). This is the second B2B relation to take into account and it corresponds also
to the “Provider Area” of application of Skinning.
Between the two existing places (1 and 2 in Figure 3.2.1) where Skinning must be applied,
the second one has been thought to be more usual in the future. The objective for Siemens
is to offer a customizable application, so that its customers can do it themselves in the
easiest way as possible. However, the application will be sometimes directly customized by
Siemens, especially in relation to the language, because one assumed customer might only
act in one country, require only one language and ask Siemens for an already
internationalized application.
Anyway, it is the task of Siemens to implement the method to customize the application,
regardless of whether the final customization will be done by Siemens or by its business
customers.
In spite of the existence of two B2B relations in this particular case, the perspective of the
problem cannot be lost; the objective is always the same: implementation of a method that
customizes (skins) a Web Application.
The words Customization, Personalization, Internationalization and Localization have been
used more than once in the diploma thesis. In order that the use of these concepts in this
Industry Example remains absolutely clear, I add a brief explanation about the reason of
using them here: The Call-Centers want that the application they use, looks like the rest of
their web site, with the same logos, colors, images, language, etc; that is, they do not want to
loose their GUI and want to be identified by the end-client, even when their end-clients enter
into the web pages of the web service they offer (such as FcB). All that implies the
customization, personalization, internationalization and localization of the application.
Once the environment of work and all the participants have been presented, it remains only
the description of the functionality of Free-Call-Button. The web service consists on the
possibility for the end-client to be called (via telephone or via PC) to receive information that
the provider (for example: Call-Center) wants to give. All that the end-client has to do is click
on a button installed on the home page of the web he/she is looking and follow all the
60
instructions that Free-Call-Button application presents: enter his/her telephone number,
choose how and when to be called, etc. Another significant characteristic of the application is
that this call will be free of charge when the end-user is called.
3.2.2
Technical aspects of FcB
Once the problem has been exposed, it must be decided which method or tool from the
theoretical study can give a suitable solution. To take the best decision, it is important to
consider the way the application has been implemented, which platform has been used, etc.
The following table and figures summarize the most important aspects of “Free-Call-Button”
web application, which have been taken into account for the proposed solution:
Characteristic
Value
Programming Language
Java + JavaScript
Platform
Java
Server
Apache, Tomcat
Layout and GUI
HTML + JavaScript + java applet
Web pages to customize (only five are call_callId.htm
relevant for the customisation)
error_callId.htm
error.htm
notificationviewer.htm
calendar.htm
Other web pages of the application
menuhaut.htm
e_401.htm
...
e_500.htm
help.htm
Table 3.2.1: Technical characteristics of Free-Call-Button
3.2.3
HTML-pages of FcB
The actual GUI of FcB has been created with the Corporate Identity of Siemens (logos,
colors, style, etc.). The following pictures give a better idea not only about the appearance of
the web sites, but also about the functionality of the application.
The first picture (Figure 3.2.2) is the home page of the Call-Center web site, where the
button of FcB will be inserted. When clicking on this button, FcB starts its function.
61
Free-Call-Button button to click
on and enter the application
Figure 3.2.2: Site of the Call-Center
with the FcB-button
(menuhaut.htm)
When the FcB-button is clicked on, a new window is opened (see Figure 3.2.3). It contains
the first site of the application. The user can in this site choose if he/she wants to be called
via Phone or via PC (1). In the first case, he/she must write his/her telephone number (2).
The number must not be showed
to the Call-Center because the
option of maintaining it hidden is
also possible (3). Date (calendar
option, see Figure 3.2.4) and
time to be called can be chosen
by the end-user too (4). If the
user needed some help or any
information about the service,
he/she could send e-mail to the
provider or consult the help
page, which is also provided by
the application (5).
Figure 3.2.3: FreeCallButton
page (call_callId.htm)
The following figure (Figure 3.2.4) shows the calendar site. This should also be different for
each client (language and GUI). Because of its size and the simplicity of its elements, the
proposed skinning method will not be here applied, and a new HTML site will be created for
each client if they want to have a personalized calendar. This idea will be again mentioned
and explained in the exposition of the
method (see section 3.3).
Figure 3.2.4: Site calendar.htm
62
When the whole site has been filled in, and the button is clicked on, the web service starts
and the next site that the end-user can see would be the following figure (Figure 3.2.5),
together with an applet that will monitor the
call. This web site informs the end-user
with a message if the call has been already
initiated, if it will be postponed, or if any
error has occurred. The applet (see Figure
3.2.6) comes into play at the same time as
the call takes place. It will inform about the
different required steps before the call is
really started (connection, routing, etc).
Each of this information is based on
pictures and notifications messages that
appear in the applet and should be also
customized.
Figure 3.2.5: Site error_callId.htm
The applet is called in the HTML site notificationviwer.htm. In this example of one of the
layouts of the applet can be seen how the user will be informed when one of the evolved
parties has answered.
Figure 3.2.6: Site notificationviewer.htm
3.2.4
Architectures of FcB
Another point to take into account before explaining the skinning solution is the three existing
architectures of FcB application depending on the place where the Call-Center’s pages are
located. As it will be demonstrated in the practice, the solution can be suitable for these three
architectures.
63
3.2.4.1 Architecture 1
The web site of the Call-Center and the FcB sites are on the same server: on the CWS
(Click-to-dial Web Server). This CWS is the server of the provider (for example: TELCO in
Figure 3.2.1), which is at the same time the direct business client of Siemens. In the
following picture the first architecture is represented (Figure 3.2.7):
Figure 3.2.7: Architecture 1 of FcB
The pages of call-center and the FreeCallButton application are also on the same server, but
normally on the Call Center’s server. It is to remark here, that the error.htm pages must be
always located on the CWS (provider of the application). See Figure 3.2.8.
64
In this architecture the pages of Call Center and the FreeCallButton pages are not on the
same server. In this case, the Call Center has only to integrate the ‘Button’ at its own page.
The FreeCallButton page and the error/information – page are also located at the CWS
server. See Figure 3.2.9 for the details.
65
After all these explanations about Free-Call-Button, the proposed solution to skin the web
application will be better understood. There will be only small differences between the three
of them, when applying the skinning method. It will be anyway suitable for any of them,
although it suits better with the third one because in that, the servlet will be called since the
first click on the FcB button and the page call_called.htm will be served. In the proposed
solution everything runs through the servlet, because it is precisely the servlet the
responsible for an important part of the customization of the sites. The details for each one
will be added when describing the solution (section 3.3)
3.2.5
Existing solution to customize FcB
This section outlines the actual way to customize FcB. I think it is interesting to explain it
now, before describing the proposed method, because the advantages of a skinnable web
application, in comparison to a not skinnable one, can be then better exposed.
66
Till now, the customization of the application must be done manually, which means
implementing new HTML sites for each client, a new jar file for the applet of each client, new
JavaScript for each necessary language, and many other changes.
Moreover, when the customer of Siemens (for example TELCO in Figure 3.2.1) must do the
customization, they must be informed about the directory structure of the server, so that they
know exactly where all the HTML sites, etc must be saved. It is not only a tedious task if the
number of clients is high, but also a quite large storage space.
When exposing the advantages and disadvantages (section 3.3.6) of offering skinnable
software to the client, references to this section will be written again.
3 Evaluation and appliance of Skinning at an existing : Skinning Model
3.3
3.3.1
67
Skinning Model: how to customize a Web Application
Considerations to decide an adequate solution
First of all, I will write about all the considerations that I have done before deciding which
technique could be used to create a web application as most customizable as possible.
Taking into account the previous section (3.2), the characteristics of the already implemented
web application to work with, are actually limitations to be considered. When I write
limitations, I mean that it is not the same to create a complete new application from the
beginning, which must be skinnable, as to make skinnable an existing one. This is the case
of Free-Call-Button, and therefore, the solution here must be always an adaptation or
continuation of the already implemented one.
The limitations of having a certain application to customize (FcB) and the properties that a
skinnable application must have, are the two most relevant concepts to consider. On account
of this, I have summarized both ideas more schematically in the following table; the points on
the left side are actually what Siemens need for its web services and the list on the right are
the limitations to be taken into account.
Conditions to customize FcB
Conditions of an skinnable application

Java (servlet)

HTML + JavaScript

A separation as the one explained by

(MVC –Model)

MVC (see Figure 2.1.2) model has not
been done


Existing
skinnable
Separation of View and Functionality
position, images

frameworks
(e.g.
Customizable: text format, colors, layout,
Language could also be considerate as a
skinning property (i18n, l10n), as it was
pajes, struts of java) have not been used
already mentioned in the master thesis.
The current Customization of FcB implies
This point will be actually one of the most
the creation of new HTML sites for each
significant ones for the Siemens interests,
client
due to its internationality.
Figure 3.3.1: Considerations to propose a solution to skin the FcB application
With this table of characteristics, it is at least clear which tools of the ones presented in
section 2.3 and which of my presented methods (see section 2.2) cannot be here used, and
they are:

68
All those tools (see Table 2.3.1) dependending on Microsoft, .NET platform, because
the Web Services presented by Siemens are thought to be independent from not only
the platform but also the operating system. Therefore, and together with other
reasons, they have chosen Java to implement the applications.

Those tools, frameworks or methods of my classification (see Table 2.2.1, Table
2.3.2, Table 2.3.4) destined to be used with other programming languages different to
Java are also not suitable.

Java frameworks to make a skinnable web application, such as Pajes (see 6.1.4.3)
and ActionServlet (see 6.1.4.1) should have been used from the beginning of the
implementation. It would be now too costly to adapt all the java code to those
frameworks, which would mean almost re-writing the applications.

Those methods of my classification (see Table 2.2.1) that do not use HTML are not
very suitable here, because all the application is based on HTML pages.
So is it, that the possibilities to prove here with FcB application boil down to:
-
Methods: It will be applied the first proposed method in the classification of the
theoretical study (see Table 2.2.1). It is actually a mixture of methods 2.2.2.2 and
2.2.2.3 where there is no dependence on the platform. From the method 2.2.2.2, I
take out the idea of using HTML with CSS as View. From the second one (2.2.2.3), I
take the concept of using a XML file that contains the necessary data for the
application. In other words, I utilize this XML file as the Content of the MVC-model.
The controller must be implemented in Java, and it will be precisely the Java servlet
of FcB application, the one that plays this role within the MVC pattern. That
describes exactly the method 2.2.2.1 and it will be actually the one that will be used
in the practice.
3.3.2
Tools: None of them is appropriate enough.
Description of the solution
In this section the main concept of the proposed solution is explained. In general terms, the
main factors of it, can be perfectly presented with the following picture (Figure 3.3.2).
69
Figure 3.3.2: MVC- model in the solution for FcB
Looking the previous picture (Figure 3.3.2), it will be relatively easy to present each of the
components that play a role within the proposed solution. All that must be done is described
in the next five points:

Creation of a template for the HTML sites that will be customized

Creation of an XML file for each client (each Call-Center must have its XML file),
which will contain the data and elements that are part of the GUI of the web pages of
FcB, and that must be inserted in the template

Creation of a CSS file for each client (each Call-Center can define its style with a
CSS file)

Creation of a JavaScript file for each language (and not for each client), to
personalize the language of messages that appear with the alert() function

Adequate modifications in the java application to make it possible that all these files
work together to create a skinnable web application
With the previous list of points, it is almost clear that the Model-View-Controller design
pattern has been also here applied:

Model: The XML file describes the content of the HTML sites

70
View: The template (HTML) represents the way the different elements will be shown
in the web + the CSS file, which represents the style of each client

Controller: Java (servlet) that makes the union between the Model and the View.
The XML file will be opened and read by the servlet, the template will be also
customized by the servlet, with the obtained data from the XML file. The JavaScript
files are also a way to add functionality to the HTML pages. If the language must not
be customized, only one JavaScript file is needed
With this solution, the most significant requirements for an application to be skinnable have
been achieved.
Besides, it means almost no effort for the Provider (see section 3.3.3) to customize the sites
of FcB for each of its clients (Call-Centers), and what is also important, if a client does not
want to customize his/her site or wants to make a total different layout, which can not be
achieved with this skinning method, he/she can always choose the option of “no template”,
and use the old way to do it (the solution described in section 3.2.5 that Siemens has till now
to customize the application). To indicate the use of a template or not, a parameter will be
given to the servlet through the URL when clicking on the FcB-button, in the following way:

With template:
- ‘http://ttm7-server/fcb/FreeCallButton?phoneCallId=bb4ac181&template=true’

Without template:
- ‘http://ttm7-server/fcb/FreeCallButton?phoneCallId=bb4ac181&template=false’
The use of this parameter implies that the HTTP interface must be extended, so that it can
be sent. This parameter will be also sent in every HTML site that compounds the application
as “hidden” parameter of a <FORM> in a HTML site. It could be also possible to save the
value of the template from the beginning, so that the HTTP interface must be extended only
in the first required HTTP request to the servlet.
The solution has been only outlined. Each component will be described in detail in the
following sections and the whole method will be also more widely exposed.
The next picture shows a flow diagram, so that the order of the facts can be followed from
the first click on the FcB button till the end of the application:
71
Figure 3.3.3: Flow diagram of the solution
3.3.2.1 The HTML Template
It has been created one template for each page to be customized and they are (List 3.3.1):
HTML site
TEMPLATES
call_callId.htm
template.htm
error_callId.htm
errorId_template.htm
error.htm
error_template.htm
List 3.3.1: HTML sites to be customized in FcB web application
The objective of the template is to create a total flexible HTML model site that can be valid
for every client. The more flexible it is, the easier to customize, the more skinnable the
application can be. Therefore, I have decided to replace all following parameters with
markers, which mean that each client may have different values for all them, since they will
be substituted by the servlet with the data extracted from the XML file (see Table 3.3.1).
Element
Objective
72
Example
Images:
The paths and names of the images are now easily replaced
<IMG SRC= 
SRC and ALT
in the HTML site, which means that all the images, logos, etc
ALT=  ...>
arguments
can be substituted simply adding a new path and name in the
XML File. SRC refers to the path and ALT to the name of the
image that appears when the mouse goes over it.
Texts
The texts can be personalized by the client, which means also
<P>  </P>
an easy way to skin the language. The XML file will have the
proper encoding rule for each language (see 3.3.2.3)
Links
Links to other sites, links to write an e-mail, etc are elements
<A HREF=  > </A>
that must be obviously personalized for each client.
Style
The path to the CSS File is also an element to personalize, so
<link rel="stylesheet" type="text/css"
that each client can have its own css file, and therefore its
href=  />
own style
Script
The path to the script file is also an element to change. In the
<SCRIPT
FcB application, it will be used only one JavaScript file pro
LANGUAGE="JavaScript"></SCRIPT>
SRC=

language and not pro client, but in other applications, the
JavaScript file could be different for each client, meaning that
the events on the HTML site are different for each client
Parameters of
This is specific for the example that I have here studied; I
ONMOUSEOVER=
<A HREF='javascript:op(,)'>
The calendar.htm is different for each client (a total new site
for each of them, therefore the path of this site has been here
added as a parameter of JavaScript function, as well as the
color of the background of the site)
Parameter
Each client is in this application identified with a number,
<INPUT TYPE="HIDDEN"
phoneCallId
which is the callId; the functionality of the application depends
NAME="phoneCallId" VALUE=>
the proper one so that when the next page is again received
by the servlet, the client can be always identified
Parameter
This parameter informs the server if the template must be
<INPUT TYPE="HIDDEN"
useTemplate
used or not. It was already said that this value could be saved
NAME="template" VALUE=”true”>
by the servlet and be send only on the first http request, so
that the http interface must be extended only once
Table 3.3.1: Elements to replace with markers and other characteristics of the template
73
With all these changes a big part of the HTML site can be easily customized, but nothing
about the style is till now mentioned. To make use of the CSS file, whose path is also known
by replacing a marker on the template, the elements of the HTML site must be identified with
the argument class, so that every component of the site may be referred from the css file and
create a different style for each of them. For instance, the different texts can have in this way
different formats (color, size, font-type, etc) between clients and also in the same HTML site.
The same occurs with the rest of elements of the site. In section 3.3.4, there is a detailed
description about what can be exactly skinned and what not with this method.
In reference to the use of CSS, it must be considered that not every browser supports the
utilization of CSS and also not every browser interprets the style-sheets in the same way.
Since I had myself this problem, I decided to write a section (3.3.2.2) about the CSS file and
support of different browsers.
3.3.2.2 The CSS file and support of browsers
As it was already explained in the previous section, the CSS file has a significant role within
the proposed skinning solution. This file will be the responsible of many aspects of the GUI’s
layout in the application, such as colors of elements, resizing, position, background images
or colors, etc. In order to create an absolutely customizable GUI, where every element can
be skinned, the argument class has been used for almost each component of the template
(images, texts, cells of tables, etc), so that they can be referred from the CSS file. See in the
following picture (Figure 3.3.4) an example of a CSS file, and the respective elements in the
template:
td.b1b2, td.b1d2, td.b1f2, td.b1a3, td.b2{background-color:"33CC00";}
New color
img.logo_call{height: 90 px;width: 90 px}
Resize
font.titel{color: "#000000";font-family: "Arial";font-size: "+18"}
Format
td.c1k2, td.c1l2, td.c1l3{visibility:hidden;}
text
Disappear
<td class="b1b2" BGCOLOR="FF6600"> </td>//the color will be replaced
…
<img class="logo_call" SRC=…ALT=… WIDTH="50" HEIGHT="50"
BORDER="0" NAME="logo"> //the image will be resized
…
<font class="titel" COLOR="#330066" SIZE="+1"
FACE="Verdana">”..”</font> //the text will have a different format
…
<td class="c1k2" COLSPAN="2"><font class ="whentocall" COLOR=
"#000000" FACE="Arial" SIZE="2"></font></td>//this text
element will not be seen in the GUI
Figure 3.3.4: Example of CSS file and respective HTML code lines
74
As it has been demonstrated with the previous figure, the use of a CSS file to modify the
elements of a HTML site is relatively easy. However, the CSS file can provoke some
problems with different browsers, because not every of them support CSS in the same way.
It is therefore very important to know exactly for which browser the application will be offered
and make only use of those elements of CSS that every of those browsers support. I had
also this problem, because in my practical work, I designed all GUIs firstly to be shown with
Internet Explorer 6.0 and when I tested the same application with other browsers (Netscape
and Opera), the results were by no means the same.
See reference [2.10] in section 5.3.1, to look for information about what each browser
supports, which must be taken into account when offering this skinning method to the
customers. It is also significant to say that new versions of browsers will have better and
better support of CSS, which means that this problem will take no much longer in the future.
Anyway, for an immediate solution for Siemens, which offers its products for the browsers:
Netscape (since version 5.0) and IExplorer (since version 5.0), is necessary to show what
could be done with CSS, so that every browser supports.
3.3.2.3 The XML file
The XML file is a simply text document where all content to be inserted in the template is
clearly structured. I add part of the XML file in the following figure (Figure 3.3.5). It can be
seen that this XML file has no more function as the one of any properties file. It is not a
complicate XML file and it is here in this example only used to save all values of the
customizable elements of the HTML template. There are other alternatives with java to
implement a properties file and they will be also commented at the end of this section (see
3.3.2.3.1.4).
The XML file will be read from the servlet to take out the content to be inserted in the
template. Therefore, it must be structured so that the time of searching and customizing is
not too long.
Firstly, referring to the structure, it is also important that each component of the template has
a direct relation and easy identification with the correspondent content field in the XML file.
Each tag of the XML file is therefore called with the same name of the correspondent
markers in the template. It is so easier for the provider (client of Siemens) to personalize the
application.
75
<?xml version = "1.0" encoding="ISO-8859-1"?> /* encoding must be the suitable for the language of textss*/
<Pages>
<enc_language>iso-8859-1</enc_language> /* argument to know which encoding must be used in the
HTML site*/
<pageid> /* page identification, so that only the necessary elements are read from the XML file*/
<pagenumber>0</pagenumber>
<path_css>"../css/tennis.css"</path_css> /*style of the site*/
<path_script>"../script/valid_temp_es.js"</path_script> /*javascript file to be used*/
<color_calendar>"33CC00"</color_calendar> /*color of the calentar.htm site*/
<path_calendar>"../page/calendar_es.htm"</path_calendar>/*path of the calendar.htm site*/
// images in the template
<image>
<path_image_0>"../images/logo_tennis_1.gif"</path_image_0>
<alt_image_0>"Identity Links"</alt_image_0>
</image>
<image>
<path_image_7>"../images/dot-wt.gif"</path_image_7>
<alt_image_7>""</alt_image_7>
</image>
// images to be changed with javascript functions; the whole function must be written
<image_change>
<image_over_0>"changeImages('contact_us','../images/contact_tennis_over.gif')"</image_over_0>
<image_out_0>"changeImages('contact_us', '../images/contact_tennis1.gif')"</image_out_0>
</image_change>
// texts to be written in the HTML site. This an easy way to customize the language
// each client can write wht he/she wants
<text>
<content_text_0>FreeCallButton</content_text_0>
</text>
….
<text>
<content_text_13>Por favor, no olvide comprobar que la línea esté libre</content_text_13>
</text>
// links in the HTML site
<link>
<path_link_0>"http://www.siemens.de/"</path_link_0>
</link>
.....
</pageid>
...
76
// the next page number will be destined for the error messages
<pageid>
<path_css>"../css/tennis.css"</path_css>
<notValid>El servidor web no está disponible. Por favor, inténtelo más tarde.</notValid>
<out>El servidor web no está disponible. Por favor, inténtelo más tarde.</out>
</pageid>
// the next page is for the customization of the error_callId.htm
<pageid>
<path_css>"../css/tennis.css"</path_css> /* style for this page. The style of the 2 sites will be often the
same. This value could be read and saved the first time the XML file is read*/
<path_applet>tennis_app.txt</path_applet> /* the applet will be only called in this site*/
<path_script>"../script/valid.js"</path_script> /*the script file is here the same*/
<image> /* images of this HTML site*/
<path_image_0>"../images/logo_tennis_1.gif"</path_image_0>
<alt_image_0>"Identity Links"</alt_image_0>
</image>
….// rest of images
….// rest of links
/* the following text are the error messages that appear in the mitte of the site*/
<ok>Su llamada ha sido iniciada</ok>
<okLater>Su llamada ha sido aceptada y será establecida en su momento</okLater>
...// rest of error messages
<noSWS>La sesión Surf no puede ser iniciada.</noSWS>
<out>El servidor web no está disponible. Por favor, inténtelo más tarde.</out>
</pageid>
</Pages>
Figure 3.3.5: Example of the XML File
With the previous picture and the explanations, the functionality of the XML file within the
method is already clear for the reader. However, all till now written corresponds to the
definitive solution for the XML file, and nothing is said yet about the intermediate trials. In
next section (3.3.2.3.1), all experiences from the practice, related to the XML file are
exposed.
3.3.2.3.1 Trials and experiences of the practice in relation to the XML file
77
In this section, experiences in relation to the XML file are exposed. The intermediate
solutions, the evaluation within the performance of the application, together with some
suggestions for other alternatives to the definitive presented method, are here presented.
3.3.2.3.1.1 Intermediate solutions for the XML file
The first implementation was not done with an XML file for each client, but an only XML file
was used for all and each client was there identified by the callId-tag. It was tested with a
little number of clients and it worked perfectly. However, when testing with more than 200
clients, the time of search for the callId along the XML file was extremely long. The obtained
times with 230 clients (size of the XML file > 1 MB), when the searched one was the last
entry of the file, can be summarized in this table (Table 3.3.2):
Java Method
Duration in seconds (with 230 Clients)
parse(): open an XML File and check the structure
> 1 sec
CallId - Search algorithm (sequential)
> 14 sec (when the desired callId was the last one)
Pagenumber – Search algorithm (sequential, there
<0.1 sec
are only 3 needed pagenumbers)
Insert the content in the template
<0.1 sec
Table 3.3.2: Obtained times in the search of the callId along the XML file
I thought about not using the method parse(), because it is actually not necessary to check
the XML file every time it is opened, about changing the search-algorithm to a better one and
about sorting the callIds. However, I decided that the actual solution, which consists on
having an XML file for each client, would be much better as correcting the search-algorithm.
There are actually two reasons why this second solution works much better:
-
The callId-search-algorithm is not more necessary. The proper XML file must just be
opened (they will be named with the value of the callId: callId.xml). Only the
pagenumber must be now searched (pagenumber 0,1 or 2).
-
The encoding parameter of the XML file must not be the same for every client; each
of them can use a different one depending on the language they want since each
one has a different XML file.
78
With all this description about the XML file, there is no more doubt about its functionality
within the proposed method.
3.3.2.3.1.2 Role of the XML file within the performance of the application
From the point of view of the performance of the application, there are a couple of things to
consider in reference to the XML file.
It was already written (section 3.3.2.3) the importance of the speed of the application when
exposing the why and wherefore of using a different XML file for each client instead of an
only one for all of them. In this section, the velocity of work of the application will be again
considered. I will present the actual times for opening and reading the XML file in different
cases, and also the times of inserting these values in the template. I think it is an important
factor for a future evaluation of the proposed skinning solution and especially for Siemens,
when they take the decision of using it or not in the next versions of their applications.
In the next table (Table 3.3.3) the important times within the customization of the template
are presented. I have made the measures for two different clients that differentiate
themselves not only in the GUI (logos, images, etc), but also in the language (Russian and
Spanish). What must be taken into account from these two differences is that their XML files
will have also a different size, which will have obviously consequences in the obtained times
when reading and parsing the XML file.
Before presenting the table, I think it will be helpful for the reader if I explain which times will
be measured and in which cases; the three functions that could have more effect in the
performance of the application are the followings:
-
parse: it is a java method that opens and checks the content and structure of an
XML File
-
readXMLFile: function that reads from the XML file all the required elements that will
be needed to customize the next HTML page to be send by the servlet
-
customize_template: it inserts all those obtained values from the XML file into the
correspondent template
-
sum of times: it will be also presented in the table the sum of the times in order to
show the approximate extra-time that the skinnable application will need in
comparison to the not skinnable one
79
The presented use cases have been chosen so that the customization of the three existing
templates (see List 3.3.1) has been measured.
Client 1: Spanish
Client 2: Russian
Size of the XML file: 7KB
Size of the XML file: 15KB
Use case 1:
Use case 2:
Use case 1:
Use case 2:
Normal Function of FcB
Error in FcB
Normal Function of FcB
Error in FcB
page=0
page=2
page=1
page=0
page=2
page=1
template.htm
errorId_
error_
template.htm
errorId_
error_
template.htm
template.htm
template.htm
template.htm
0.012564
0.012234
0.016046
0.021706
0.009137
0.023036
sec.
sec.
sec.
sec.
sec.
sec.
Read
0.008142
0.004308
0.001615
0.009105
0.003906
0.001403
XMLFile
sec.
sec.
sec.
sec.
sec.
sec.
customize_
0.040300
0.005550
0.000200
0.043882
0.005117
0.000201
template
sec.
sec.
sec.
sec.
sec.
sec.
Sum of
0.061006
0.022092
0.017861
0.074693
0.018160
0.024640
times
sec.
sec.
sec.
sec.
sec.
sec.
Method/
Function
Parse
Table 3.3.3: Measured times of the customization of the template
3.3.2.3.1.3 Conclusions of experiences with the XML file and the measured times
Some interesting conclusions from the results presented in Table 3.3.3 are described in the
following paragraphs:
First of all, the results of the total sum of times represent clearly how much time more will be
needed in the skinnable application in comparison with the no skinnable one. It is a factor to
take into account when deciding if the proposed solution is suitable to be applied in future
versions. The difference between having a XML file of 7KB and having one of 15KB is only of
0.01 sec, when customizing the first page, and it is so because of the parse() method. It must
be taken into account that, the bigger the XML file is, the longer will last the parse() method.
Apart from this, there is no more significant difference between the times measured for the
two different clients (the two different sizes of XML file). That makes that the alternative of
80
opening the XML file only once, instead of opening and reading it each time a page is sent,
could be in some cases a better solution. I have not implemented it but a consideration about
the supposed times can however be done, using the results from Table 3.3.3.
Suggestion of an alternative to reduce the measured times:
The idea would be opening the XML file the first time it is needed, read all elements of it, for
the three existing templates, and save the values, so that in the next call to the servlet, only
the insert of values in the template must be done. Making use of the times of Table 3.3.3, the
results for two different clients are the followings:

Client 1(Spanish, 7KB) and use case 1 (without error):
-
Send the first page (template.htm) would last:
o
parse(): 0.012564 sec
o
readXMLFile (the whole of them and save the required values for the next
templates): 0.008142 sec + 0.004308 sec
o
customize_template: 0.040300 sec
o
total sum: 0.065314 sec (0.004308 sec longer as what was presented in
Table 3.3.3)
-
Send the second page (errorId_template.htm) would last:
o
parse(): 0 sec; it must not be done
o
readXMLFile(): 0 sec; it must not be done
o
o
total sum: 0.005550 sec (0.016542 sec shorter as the result from Table
3.3.3)

Client 2 (Russian, 15KB) and use case 1 (without error):
-
Send the first page (template.htm) would last:
o
parse():0.021706 sec
o
readXMLFile (the whole of them and save the required values for the next
templates): 0.009105 sec + 0.003906 sec
o
o
total sum: 0.078599 sec (0.003906 sec longer as what was presented in
Table 3.3.3)
-
Send the second page (errorId_template.htm) would last:
o
parse(): 0 sec; it must not be done
o
readXMLFile(): 0 sec; it must not be done
81
o
o
total sum: 0.005117 sec (0.013043 sec shorter as the result from Table
3.3.3)
Conclusion to this alternative:
In general terms, reading the XML file only once, implies that the performance of the
application in the first use case would be: - 0.004308 + 0.016542= 0.012234 sec faster and
for the second one: - 0.005117 + 0.013043 = 0.007926 sec faster.
However, there are a couple of points that have not been here considered. First of all, there
are many possible error/information messages of the errorId_template.htm and till now, with
the solution I have implemented (reading the XML file each time a page is sent), only the
needed error/information message was read because the status of the application was
known, since it is determined in runtime (when for example the user determines the time of
call, or an error occurs suddenly). On the contrary, when opening only once the XML file, all
the values must be read and saved, since it is unknown what will choose the user or what will
happen with the application. This means that the used times from Table 3.3.3 cannot be so
exactly considered. The times required for the readXMLFile method when sending the first
page would be therefore a bit longer (< 0.005 sec) as supposed. Assuming a maximal extratime of 0.005, the final value of the improvement would be at least: 0.012234 – 0.005 =
0.007234 sec faster as the first solution for the first client (Spanish) and at least: 0.007926
– 0.005 = 0.002926 sec faster for the second use of case (Russian).
Comparing these two last assumed results of time improvement when reading the XML file
only once, for client 1 (size of XML file 7 KB) and client 2 (size of XML file 15 KB), it is
something to notice; surprisingly, the improvement has been better for the smaller XML file
(0.007234 sec) than for the bigger one (0.002926 sec). It is because when applying the
method parse() twice, the second time will be always shorter than the first time. The longer
the first time lasts (bigger XML file), the more advertent will be the difference between the
times of the first and second parse() call.
Once the use of the XML file, as well as its performance, have been evaluated, it can be
considered if its use will be profitable or not for the application. If the presented times were
too long for what Siemens expects for the performance of its Web Services, different ways of
optimization could be suggested. I describe in the next section (3.3.2.3.1.4) other possible
alternatives to play the role of the XML file in this proposed skinning solution.
82
3.3.2.3.1.4 Other alternatives to replace the XML file functionality
Since the point of view of the performance of the application, the presented times in Table
3.3.3 could result too long if the number of simultaneous access of end-users to the same
server is very high. Therefore I make a suggestion in this section of another possible
alternative to replace the role of the XML file in the proposed skinning solution. A list of
advantages and disadvantages of this alternative, as well as the reasons of having decided
to present my solution with the XML file, instead of with any other, are presented in this
section.
One first way to implement the function of the XML file would be the creation of a Data Basis
where all these values of customizable elements of the HTML sites were saved. I will not
extend this alternative, nor implement it, because I think it would be too complicate and an
unnecessary waste of place to maintain a Data Basis in order to replace the role of the XML
file in this skinning solution. It is obviously much easier to create new XML files as to create,
administrate and manage a Data Basis. I write this suggestion here only for those readers
that may be interested in other alternatives and could find the idea of the Data Basis
appropriate for their application.
Considering that FcB has been implemented with Java, the classes that this programming
language offers, can be utilized for implementing the second alternative. One of these java
methods will be precisely the possible substitute of the XML file within the skinning solution.
This java class is named “ResourceBundle” and it was implemented for the introduction of
internationalization and localization in the Java programming language. It is based on the
creation of one properties file for each desired language, with all the texts that will be shown
in the web application. All these properties file must have the same content but in different
languages and are also named similarly: only the three syllables that identify the country, the
language and a possible variant, differentiate the names of the properties files. For example,
in order to have the application in Spanish, English and Russian, three properties files would
be needed and named as follows: “ResourceBundleName_language_country_variant”. For
the three examples, it could be done, for instance:
-
English in the United Kingdom: MessagesFcB_en_UK
-
Spanish in Spain: MessagesFcB_es_S
-
Russian in Russia: MessagesFcB_ru_RU
Besides the ResourceBundle object, a Locale object must be defined in order to determine
which properties file will be used during the runtime of the application. From the java code,
83
any of these ResourceBundles is created with the proper Locale for the client and the
properties file is accessed with a simple call to the java function, in order to read the
customizable elements of the application:
-
ResourceBundle.getString (“name_of_the_string_to_read_from_properties”)
These mentioned classes were created in Java to change the language of an application
automatically. However, it can be obviously used for reading the value of any customizable
element of the application. Therefore, the XML file could be perfectly replaced with one of
these properties file, in the following way:
enc_language = iso-8859-1 /* argument to know which encoding must be used in the
HTML site*/
path_css_page0 = "../css/tennis.css" /*style of the first page*/
path_script_page0 ="../script/valid_temp_es.js" /*javascript file to be used*/
color_calendar = "33CC00" /*color of the calentar.htm site*/
path_calendar = "../page/calendar_es.htm"/*path of the calendar.htm site*/
// images in the template
path_image_0="../images/logo_tennis_1.gif"
alt_image_0="Identity Links"
…
// and so forth with the rest of the content of the XML file
This ResourceBundle Method has been actually utilized till now in the FcB application for the
internationalization of all those error/information messages in the correspondent HTML
pages: error_callId.htm and error.htm. However, the way in that it has been implemented
does not allow an automatic change of the language for each customer, because the
definition of the Locale object has been asserted to the configuration file. When the servlet is
initiated, it will be read the language and country from the configuration file and it will be fixed
for the whole application. The next lines of code show how it has been implemented in FcB:
String language=confFileManager.getString("LANGUAGE");/*confFileManager is
another ResourceBundle to read the properties file of the configuration*/
String country=confFileManager.getString("COUNTRY");
String addMessages=confFileManager.getString("addMessages");
// the Locale remains unchangeable for all the customers of this Server
Locale currentLocale=new Locale(language,country);
_messages=ResourceBundle.getBundle(addMessages,currentLocale);
84
The way to make that each client (each Call-Center) has its properties file and with it, a
skinnable GUI and language is separating the definition of the Locale from the configuration
file. An easy form to achieve it, could be for example naming the changeable part of the
name of the properties files with the callId of each client. See the following table (Table 3.3.4)
for three different examples:
CallId
Language
Name of the Properties File
tennis
Spanish in Spain
MessagesFcB_es_SP_tennis
bb468ce9 English in the USA
MessagesFcB_en_USA_bb468ce9
bb4ac181 Russian in Russia
MessagesFcB_ru_RU_bb4ac181
Table 3.3.4: Examples to name the properties files of the callIds
I have regrettably not implemented this method for the servlet during the practical work of my
diploma thesis. However, I wanted to add it here as a suggestion for possible future
implementations of FcB, as I have already mentioned at the beginning of this section.
Moreover, I have utilized this variant to skin the applet (section 3.3.2.7) and demonstrated
that it works properly.
Before finishing this section, a couple of advantages and disadvantages of using
ResourceBundle instead of the XML file for the customization of a web application are
presented:
Advantages of ResourceBundle (in comparison to the XML file)
-
It means no loose of time, while the XML file requires more time to be opened and read
(see Table 3.3.3)
-
It takes up less space in the server (the XML file is obviously bigger because of its
structure)
-
It is a java method and therefore it is no necessary to import all required packages to
work with an XML file:
-
o
javax.xml.parsers.DocumentBuilderFactory
o
javax.xml.parsers.DocumentBuilder
o
org.xml.sax.SAXException
o
org.xml.sax.SAXParseException
The way to code it is relatively easier
85
Disadvantages of ResourceBundle (in comparison to the XML file)
-
It should be manually written, while an editor to write XML automatically can be always
found and used
-
The fact that the parse () method can be used is also an advantage, since the structure
of the XML file will be checked, while there is no way to test the properties file of
ResourceBundle
-
The XML file can be always utilized, in any web application, regardless of the
programming language of the application is java or not
-
The properties files from ResourceBundle must always be saved as ASCII files, which
is a bit problematic with those languages that have different characters to those
installed in the machine. It is actually not so difficult to solve this problem. It must be
done only a conversion of ASCII into Unicode. Java offers a tool that makes it
automatically: native2ascii. That is not necessary to be done with the XML file. See the
section of skinning the applet (section 3.3.2.7) for more information about this
conversion.
Why have I used the XML file for my proposed skinning method?
Once that the advantages and disadvantages of the two possibilities of implementing the
Model of the application (from the MVC design pattern), I would like to explain the why and
wherefore I have decided to expose the solution with the XML file and not with the java class
ResourceBundle.
On the one hand, the use of ResourceBundle has some advantages since the point of view
of the performance of the application, when it is compared to the use of an XML file.
However, it cannot be forgotten, that this is only applicable when java is the programming
language of the web application.
On the other hand, in my opinion the XML file works properly enough to convert FcB into a
skinnable web application. Moreover, it has also a couple of advantages (disadvantages of
ResourceBundle), and which is more important, it suits much better as a general skinning
method than ResourceBundle, which is a particular and exclusive class of Java.
Fortunately, one method does not reject the other, which means that both can be together
used and the one can always complement the other. I make this suggestion, especially for
FcB and similar Web Services of Siemens, where Java is the main programming language
and the use of ResourceBundle can be in many cases more profitable. Each web application
86
should be separately analyzed and the most suitable method from the two here presented
could be particularly chosen.
Finally, in my opinion, a general “Skinning Method” cannot have a component that is totally
dependent on a certain programming language. Therefore it must be separated the concept
of “Skinning Method”, which is actually the objective of my master thesis, from the possible
variants or modifications that this general method can suffer in order to adapt it to a particular
application, such as, for example, the Web Services of Siemens, where all the tests for the
practical work of the thesis have taken place.
3.3.2.4 The Servlet
In this section, the controller of the proposed skinning solution is outlined. As it was already
explained in Figure 3.3.2, the servlet has here the role of the controller and it will make the
connection between the model and the view.
First of all, a brief description of the servlet and the interworking of the Handlers of the
application will be presented, so that it can be better understood, how and where has been
the java code changed to implement the controller of the skinnable application. See picture
(Figure 3.3.6) to view the involved methods within the servlet of FcB:
Figure 3.3.6: Description of the servlet in FcB
87
As the previous figure (Figure 3.3.6) represents, the adequate PageHandler will each time
handle the different main methods (validate and serve) with the correspondent functions
(read, customize, send, etc).
The interworking of these components, since an end-user clicks on the FcB-button till he/she
is called free of charge can be shown in Figure 3.3.7:
Figure 3.3.7: Description of the FcB servlet in the normal functionality of the app.
In the next figure (Figure 3.3.8) the same example of FcB servlet will be presented, but
remarking in red and orange the main modified methods of the java code. As it can be seen,
the structure is still the same and the whole acting of the servlet will be always decided
according to the received parameter useTemplate. If this parameter has any other value
different to “true”, no change of the code will be noticed. On the contrary, when useTemplate
is equal to “true”, the new-implemented code will take place in the application.
88
First of all, the method validate() asks if the template must be used or not. In the case of
using it for the customization, the name of the page to be sent is template.htm, instead of
call_callId.htm.
Secondly, when serving the certain page, the template will be customized with means of the
XML file. It is read and all the values are inserted in the template.
Finally, I had to modify also the write() method, because of the internationalization of the web
application. The HTML sites in some languages need to be encoded so that all the
characters of the site can be interpreted. I had here some difficulties at the beginning
because I tried firstly to encode the response when it is sent by the servlet with the print()
method of java. This method does not support sending an encoded text and therefore, it was
necessary to implement a new java class that extends the PrintWriter, as follows:
public class MscPrintWriter extends PrintWriter
{
public MscPrintWriter() throws UnsupportedEncodingException {this(null,null);}
public MscPrintWriter(OutputStream out, String encoding) throws
UnsupportedEncodingException {
super(new BufferedWriter(new OutputStreamWriter(out,encoding)), false);}
}
The code in the write() method of the FcB servlet would be the following:
if(_useTemplate.equals("true"))
{
response.setContentType("text/html; charset=" + encoding );
response.setContentLength(_pageHtml.length());
MscPrintWriter out = new MscPrintWriter(response.getOutputStream(),encoding );
out.print(_pageHtml);
out.close();
}
The problem in the previous code was that when the response was encoded, for example
with Unicode, the length of the encoded response was bigger as the not encoded one.
Therefore, the String that has the content of the HTML site must be firstly encoded; then the
length of the response must be set and finally, the encoded page can be sent. See the
following code:
89
if(_useTemplate.equals("true"))
{
//the HTML site to send must be encoded with the proper code of this language
byte [] b_temp = _pageHtml.getBytes();
//parameter encoding will be read from the XML file too
String temp = new String(b_temp, encoding);
response.setContentType("text/html; charset=" + encoding );
//the length must be also set and always before having encoded it, because for
//example, unicode is always longer as any other code
response.setContentLength(temp.length());
//the new implemented class must be here also used to encode what is send
MscPrintWriter out = new MscPrintWriter(response.getOutputStream(),encoding );
//send the HTML site;it will be encoded by //the print method
out.print(_pageHtml);
out.close();
}
The next figure (Figure 3.3.8), as it was already mentioned, shows these previous
explanations graphically:
Figure 3.3.8: Description of the FcB Servlet when the app. has been skinned
90
The main changes to the servlet have been already exposed. The rest of them are only
littlenesses and there is no much more to comment about them.
Both figures presented in this section (Figure 3.3.7 and Figure 3.3.8) about the FcB-Servlet
correspond to the third architecture of FcB (see section 3.2.4), in which all HTML sites are in
the provider´s server. In the following section (3.3.2.5) a couple of comments are written in
reference to what must be taken into account in each of the three existing architectures.
3.3.2.5 Solution particularized for the three architectures
In this section the solution is particularised for each of the three architectures (see section
3.2.4) of FcB. The skinning solution proposed in the master thesis works with all them but
with some differences, which are based on the fact that the servlet is required to customize
the template. Therefore, in those architectures, in which the first HTML site of FcB is in the
Call-Center’s server, the servlet of the application will not be called to serve this first page.
That means that this must be a new HTML site, created by the Call-Center if it must be
customized, or a copy of the one offered by the provider. On the contrary, the rest of the sites
of the application could be customized with the proposed skinning method in this master
thesis.
3.3.2.5.1 Solution for Architecture 1:
FcB’s HTML pages and Call-Center’s home page are at the FcB-server, therefore in the first
html site, when clicking on the FcB-button, the link is the following:
<.…HREF="javascript:window.open('http:../../freephone_call/call_callId.htm?phoneCallId=
abcd1234)">
In this case the first HTML site (call_callId.htm) exists locally at FcB server, the servlet will
not be called, and therefore the template will not be used. The Call-Center is responsible for
the complete page. If the client wants to use the template in the other HTML sites (error.htm
and error_callId.htm), the “template” parameter must be added in page call_callId.htm:
<INPUT TYPE="HIDDEN" NAME="template" VALUE="true">, so that the servlet reads from
the template and customizes the next served pages.
FcB’s pages and Call-Center’s site are at the Call-Center server. It is the same solution as
the previous one, only that a specific FcB page for the Call-Center must exist, but there are
no more differences with Architecture 1.
91
In this case, FcB and Call-Center’s pages are not located on the same server. Therefore, the
template can be used with the first site call_callId.htm too.
The link when clicking the FcB-button to receive the first page of the application would be:
<AHREF="javascript:window.open('http://ttm7server/fcb/FreeCallButton?phoneCallId=ten
nis&template=true')">
The servlet will be than called and it recognises the use of the template with the parameter
template=true and does the necessary to customize it.
If the parameter is template=false, the servlet will read by default the call_callId.htm page,
created by the client. That is the case of a client, who does not want to use a template and
chooses the design by default or a complete new HTML site that he/she has created with a
total different layout from the template, which cannot be achieved with the technique of
Skinning.
It must be taken into account that if the template is chosen since the beginning, the rest of
HTML pages of the application (error.htm, etc) will be also created with a template.
Otherwise, if the first page (call_callId.htm) is not created with the template, using it with the
rest of HTML sites is even possible, only by adding the hidden parameter template=true in
the first created HTML page.
3.3.2.6 Graphical examples of the solution
This section is one of the most explicative and representative of the whole chapter 3, just
because it is precisely in this subchapter, where the graphical results of the implemented
method are exposed.
The best way of presenting these three different layouts is to show firstly the original web
pages of Siemens (Figure 3.3.9) and secondly, to mark the skinned elements in the new
GUIs, comparing them with the original one.
92
Figure 3.3.9: Web Pages of Siemens style
I have chosen three different styles to present:

The first one is similar to the original layout of Siemens, though all the typical
Skinning properties can be there demonstrated; colors, text-format, images, invisible
elements, language, links, etc are in this style customizable (Figure 3.3.10)

In the second one, I have tried to make a more different layout to the one of Siemens
style, with the same concept of Skinning, in order to prove what can be actually
93
achieved with this method and how fix it can be, when a client wants to move every
element of the site (Figure 3.3.11)

In a third and last one, I have tried to add new images that were not fixed within the
template. That is, the path of the image will not be read from the XML file, but CSS
will be used to insert a picture in a cell of an existing table of the template (Figure
3.3.12).
Figure 3.3.10: Skinned FcB (Style 1)
94
95
3.3.2.7 Skinning the applet
The proposed skinning method for the web application has been modified a little for the
applet’s customization. The idea of separating the content and the view of the application will
be also applied, but the content will be no more implemented by a XML file, but by a
properties file related to the java class ResourceBundle. See the following figure to view the
components of the MVC-Model of the skinning solution for the applet:
Figure 3.3.13: MVC-Model when skinning the applet
The reasons of having implemented with the applet a variant of the first proposed skinning
method are in this section also explained. Actually, the why and wherefore of having modified
the general skinning method is that it has not properly worked with the applet. To explain the
idea, I will describe in the following paragraphs the intermediate solutions that I thought for
the applet, before achieving the definitive one, and the reasons of having rejected them.
Firstly, I make a brief description about the applet of FcB; it will be always called from a
HTML site (notificationviewer.htm), which is shown in a small new window that is opened
with the following JavaScript function:
window.open (“path_html_site?parameter1=value1&parameter2=value2+ more
parameter for the JavaScript function”);
96
This line of code is inserted in the HTML site errorId_template.htm by the servlet when the
customer wants to have the monitoring option (this option consist in viewing the applet,
where the steps of the call will be shown till the end of it). So it is, the applet comes into play
together with the errorId_template.htm and will show the different stages between the calling
parts. It is important to mention these details because the way that the applet will have to
recognise which client is served, is precisely reading the parameters that the servlet inserts
in the JavaScript function.
Once the implementation of the applet has been exposed, the different tested solutions will
be described.
3.3.2.7.1 Solution 1:
This first solution consists in having a different .class file, which means also a different .jar
file for each client. The texts and images will be written direct in java code and a new .java
file is needed for each client or language, when only the internationalization comes into play
and the pictures must not be customized.
The name of the .class and .jar file of the applet will be known through a parameter in the
window.open JavaScript function. These values are also values that the servlet reads firstly
from the XML file that identifies each client.
Reasons of rejection:
It is by no means a good method to skin the applet.

A big part must be manually done; that means it is not a good skinning method, but
only a way to achieve a customized applet.

Not only a new .class file is required for each client, but also a new .jar file. That
implies a big extra storage place and an important waste of time every time the applet
must be customized:
o
Modify the java code
o
Compile to create the .class file
o
Create the new .jar file and save it on the server
97
3.3.2.7.2 Solution 2:
The second solution corresponds exactly with the proposed skinning method for the rest of
the web application (see section 3.3.2). The applet was supposed to read from a XML file,
where all texts and paths of images are written. An only .jar file would have been enough for
all clients. However, the problem with the applet is that the java classes that make it possible
to read an XML file cannot be found and a SAXException comes when compiling the
application. It would be possible to compile it without exceptions if the java classes related to
a XML file were added to the jar file and downloaded with it.
The only way that this solution can work is adding in the jar file the SAX package of java,
which means an extra size of 600Kb. Since the point of view of the performance of the
application, that is a weighty argument to reject this solution automatically.
3.3.2.7.3 Solution 3:
After the results from solution 2, I tried to replace the XML file with a normal text file, where
all texts and images to be displayed are written. With this solution a unique .jar file would be
enough for all clients. One advantage of it is that the text file must not be included in the jar
file, because the URL method from java classes makes it possible to open a connection with
the server and read from this text file.
Those languages that need another encoding (Japanese, Chinese, Russian, etc) different to
iso-8859-1 (encoding for Latin languages) could not be read because the applet cannot find
the java classes that make the conversion from byte to any other encoding different to iso8859-1 (for example: java.io.ByteToCharunicode.class) when compiling the code, and gives
an IOException.
3.3.2.7.4 Solution 4:
Finally, the last and definitive solution, which was already mentioned but not explained at the
beginning of this section (see section 3.3.2.7), is based on a properties file and
ResourceBundle method of Java. It can be achieved exactly the same as what the solution 3
tried to do. This java method was already exposed in section 3.3.2.3.1.4, when exposing
other alternatives to the XML file.
98
Since it is the definitive and best solution of the four presented ones, I will explain it in full
detail in the following points:

The java code of the Servlet replaces the marker  in the
errorId_template.htm HTML site. See the following lines of code, where the key
parameters for the solution have been marked in bold:
insert("monitoring","window.open(\"../applet/notification_viewer_fph.htm?callId="+callId+"&lan
guage="+language_code+"&country="+country_code+”&phonecallId="+_phcallId+"&text
="+errorText+"\",\"notif\",\"width=360,height=190,toolbar=no,menubar=no,location=no,scroll
bars=no,resize=no\");");

In the HTML site (notification_viewer_fph.htm), where the applet is called, the
parameters must be also read with java script, so that the applet can use them:
var temp1 =
document.location.search.substring(document.location.search.indexOf("language=")+9);
var language_code = temp1.substring(0, temp1.indexOf("&"));
var temp2 =
document.location.search.substring(document.location.search.indexOf("country=")+8);
var country_code = temp2.substring(0, temp2.indexOf("&"));
var temp3 =
document.location.search.substring(document.location.search.indexOf("_phcallId=")+10);
var phcallId = temp3.substring(0, temp3.indexOf("&"));

In the java code from applet, these parameters can be read in order to know which
properties file form ResourceBundle must be used and which Locale object must be
created:
String language=getParameter("language_code");
String country=getParameter("country_code");
String variant=getParameter("phcallId");
String messagesName=”MessagesFcBApplet”; /* the same properties file could be here used as
the one for the rest of the application but it is important that this properties file is saved in the
same directory where the jar file of applet is it could be also defined as a Parameter from the
HTML site*/
Locale currentLocale=new Locale(language,country, variant);
messages=ResourceBundle.getBundle(messagesName,currentLocale);
99
Once the ResourceBundle is created, the texts from the properties file can be easily

read:
messages.getString("name_of_the_key_that_identifies_the_string_in_the_properties_file");
Finally, I will resume a set of points where I had difficulties, and that must be always taken
into account when implementing this solution (List 3.3.2):

The properties file will be named as follows:
NameoftheResource_language_country_variant
f.e. : MessagesFcBApplet_es_SP_xxx

The properties file must always be saved in the same directory as the jar file of
the applet, so that it can be found by the java method

The properties file must be firstly created and saved as an ASCII text file. In order
to be used with any language, the most profitable way to do it, in my opinion is to
use the native2ascii tool of java. With this tool, the ASCII file can be easily
encoded into unicode with a simple unique command line:
native2ascii –encoding UTF8 input_file_name output_file_name
I had problems when using other encodings, different to UTF8, because the
conversion was not properly done. Therefore I suggest to use always UTF8 with
this tool or make a test with the needed language and choose the suitable
encoding.

All that must be customizable (different for each customer) in the applet must be
in the properties file: texts, images, etc. What must be also considered are the
characteristics of the awt elements in the applet, such as type of font (not every
font is installed or even available to be used in all languages).

Another important point to take into account in the customization of the applet is
that not every language needs the same space to be shown and therefore the
resizing, indexing, etc of the text within the awt elements must be always done,
which means implementing a general code, that can be suitable for all languages.
List 3.3.2: Interesting points when skinning the applet
100
The main points and difficulties when skinning the applet have been written. I will end this
subchapter with a picture (Figure 3.3.14), where the applet is skinned. They have only a
different language but customizing the images would be so trivial like adding them in the
properties file:
Figure 3.3.14: Examples of the skinned applet
3.3.2.8 Other existing HTML sites in the FcB application
This section is dedicated to those HTML sites that must not be customized or will not use the
proposed skinning method to be customized:
3.3.2.8.1 Calendar.htm: a different calendar for each client
This html site will be almost sure different for each client, but it has not been customized with
the proposed skinning method, due to the following reasons.
Firstly, it has no sense to make a template for it, because it is much easier and faster to
create a new HTML site, due to the few elements that it has. Customizing the template would
be much more costly than creating a new HTML site.
101
The site is called from another HTML site and managed by code in java script. There is
something that could be here customized: the way the date is shown in the HTML site from
which the calendar is called. The application works so, that the chosen date by the end-user
in the calendar.htm site, will be also shown in the call_callId.htm site, where the calendar
was called. The way the date is in this site presented has not been internationalized, that is,
it has a fixed order and format. The way to localize it for each country/customer would be
through the JavaScript code of the calendar site.
In order to know which calendar.htm must be opened for a certain customer, the path of this
calendar.htm site has been added as another entry of the XML file, so that it is read directly
from it where to find the site for each different client. If only the color of the background of
calendar.htm site must be changed, there is also an entry for this property in the XML file.
3.3.2.8.2 error400.htm….error.500.htm
These HTML sites are used to alert the user of some typical errors that can occur on the web
server, such as:

e400.htm: Bad Request. Your request cannot be completed

e401.htm: Authorization Required. You are not authorized

e403.htm: Forbidden. Sorry, you do not have permission to access this server.

e404.htm: Document not found. Sorry, the requested URL was not found on this
server.

e500.htm: Internal Server Error. The server encountered an internal error or
misconfiguration and was unable to complete your request.
They are fixed in the initialisation of the web server; therefore the proposed method cannot
be used. Moreover, it is not so relevant that these sites are personalized for each call-center,
since most of these errors occur even before the end-client has entered in call-center’s web
site.
Although in the case of FcB web application it is not worth at all to customize these sites, I
have read something about customizing these error pages and the methods that can be
there used.
The topic of this master thesis is actually “Skinning in web applications” and therefore, it is
also interesting to write about the way to customize these error sites, since they are always
present in any web service.
102
First of all, Apache can be configured to do one of the four following things in the event of
errors:
1. Output a simple hardcoded error message
2. Output a customized message
3. Redirect to a local (relative) URL to handle the problem/error
4. Redirect to an external URL to handle the problem/error
The default configuration is to output a simple hardcoded error message (Option 1). Options
2 to 4 are configured within the .htaccess file with the command ErrorDocument:
ErrorDocument 401 http://www.xxxx.xx/~callId/xxx.html
ErrorDocument 403 http://www.xxxx.xx/~callId/xxx.html
ErrorDocument 404 http://www.xxxx.xx/~callId/cgi-bin/xxx.pl
ErrorDocument 500 http://www.xxxx.xx/cgi-bin/tester
Not only a redirection to a new-implemented HTML site can be done, but also a program can
be started. The servlet (or another new servlet) could be here called and the proposed
skinning method applied. I have not implemented it with FcB, because the most error pages
come into play even before the phoneCallId is known, and in the use case of FcB, it is
precisely the callId the one that determines which properties file must be read in order to skin
the application.
3.3.3
What must the provider do to customize the sites of a new client
From the point of view of the commercialization of the web application, it should be evaluated
what must do a provider in order to customize the application for each of its customers.
Therefore, this subchapter, together with the next one (3.3.4) will be in some terms,
determinant when deciding if a new installation and production of the skinnable version of
FcB will be worth or not. It is a fact, that every business-client of Siemens will want to know
how difficult or how much effort must be inverted to personalize the application for every
client.
The proposed solution makes it relatively easy for a provider to customize the FcB web
application. All that must be done can be summarized in the next 4 points:

Have a total knowledge of the structure of the template and which parts of it are
fixed and which of them are skinnable (see section 3.3.4). Siemens should give their
customers the proper documentation about it

103
Create a .css file with the style that the client (call_center) wants. To make it
properly, it is very important to know the class argument of each element on the
template and consider for which browsers must it work (see section 3.3.2.2)

Create an XML file for each client (callId.xml) with all the contents to be inserted in
the template (paths, images, links…). I think it would be a good idea for Siemens to
offer a tool (such as the company SAP makes with its SAPEditor, see section 6.1.6.1
to take the idea), which asks for every element on the XML file and on the CSS file,
and create both automatically, so that their business clients do not make errors when
creating those files, which would mean an error in the whole skinning method

Save all files and images, etc of the client in a suitable structure of directories. I would
propose the following one:
-
All original html sites (for those who do not want to use the template) + the
template in the /…/htdocs/freephone_call directory
-
All the images in the /…/htdocs/images/callId
-
All the css (only one for each client that uses the template is enough) in the
/…/htdocs/css
-
Script files /…/htdocs/script
-
The XML file in /…/htdocs/xml
-
The .jar file, properties files and images of applet in /../applet
With these previous points, together with the explanations of section 3.3.2.5, concerning to
the solution for each architecture of FcB, is already clear which modifications must be done
by the provider to offer a skinnable web service.
3.3.4
Possibilities and limitations of this method
3.3.4.1 Possibilities: What can be skinned
As it has been explained in the previous sections all the typical properties of Skinning can be
achieved with this method. How difficult or costly for the provider is to skin the application
depends on how many changes the client wants in the GUI.
On one hand, there is a set of things that are very easily skinned, which are:

Exchange logos und images with other ones, but in the same position where the
original were
104

Making some images or text elements invisible

Change the size of the logos and images

Change the text (language, format, etc) but in the same position where the
original text was

Exchange the colors of the background

Exchange the links with other ones but also in the same position

Make elements of the site invisible, so that they have no function in the
application, for example, the FcB service without calendar
On the other hand, there are some changes, apart from the ones listed before, that could be
made in the layout, but dedicating much more time in studying the possibilities that the
template can offer. For example, the position and size of the elements can be with .css
specified. However, there some always some limits because of the way the template has
been constructed. What I mean with this consideration is that the template has a structure of
tables, with different cells and this is actually difficult to modify. The possibility of creating a
more flexible template should not be discarded.
An interesting point to remark is that the language, one of the most desired characteristic by
the customer is very easy replaceable. That is, the internationalization of the web application
is one of the things that can be always achieved.
3.3.4.2 Limitations: What can not be skinned
It is a bit difficult to precise what cannot be skinned at all, however it must be clear that there
are two main factors, because of which the provider can find some problems when trying to
skin some elements:

The template has a fixed structure of tables and a fixed maximum number of texts
and picture-elements

The excessive use of CSS in the design of GUIs may cause problems with some
browsers (see section 3.3.2.2 for the details of browser’s support of CSS)
In the following picture (Figure 3.3.15), the image of the template and its table-structure can
be observed. The colors are exchangeable, the images and texts replaceable, but the cells
will always be there.
For instance, one of the things that the client could not do with this method is to add more
text elements than the planed ones for the template. A maximum is fixed, because if no more
105
markers exist, the texts cannot be inserted. It is again here demonstrated that Skinning
technique has always some limitations. When I described the advantages and disadvantages
of Skinning in section 2.1.8, the decrease of “expressiveness” was added as a disadvantage.
This is something that can be now better showed: it is not possible to create any new layout
when the decision of using a skinning technique has been done.
If one customer wanted to create a total
different layout, the template should not be
used and the actual existing solution of
customizing FcB should be applied (see
3.2.5) with the disadvantage of inverting
much more time and effort to do it.
Figure 3.3.15: View of the template.html without being customized
3.3.5
Problems and difficulties during the practice
In this subchapter, I will mention again the main difficulties that I had during the practical
work of my master thesis. Most of them have been already described along this chapter;
therefore I will make also references to those sections when exposing them here. The
following list of points show these problems schematically, and more to them comes in the
following paragraphs:

Working with an already implemented java application

First solution was thought to use only a XML file for all clients: too slow

Internationalization: encoding of the HTML site, XML file and output of servlet

Support of CSS of the required browsers by Siemens

Applet: problems with the XML file, with the encoding and the adaptation of
graphical elements to different language sizes
List 3.3.3: List of problems and difficulties during the practical work
106
First of all, I had to work with an already coded application, which implies a waste of time to
understand the whole functionality and the role of each java class within the entire
application.
Secondly, the very first solution was thought to use only one XML file for all clients and that
was too slow, as it has been already explained before (section 3.3.2.3 and Table 3.3.2 to see
the measured times).
Another difficulty was the internationalization, what means the use of different languages.
The main problem here was that not every language has the same alphabet, which in
computer terms means the use of a different encoding mode. In order to make it possible,
the following modifications had to be done:

In the XML file:
o
Use the proper encoding parameter:

o
Add an encoding tag to be read by the servlet


<?xml version = "1.0" encoding="ISO-8859-1"?>
<enc_language>iso-8859-1</enc_language>
In the Java application (servlet):
o
New java class that extends PrintWriter in order to send the data to the client
with the proper encoding parameter. Java has an encoding by default (iso8859-1), which is only valid for the languages that come from Latin. Therefore,
for any other language (Russian, Chinese, etc.) the suitable encoding
parameter must be explicitly added. It should be valid for all languages the
Unicode/UTF8
o
When using Unicode as encoding, I had firstly problems with the size of the
html site that the servlet reads, which is in this case the template. It must be
also encoded with Unicode before setting the length of the content of the
response. I had not noticed it, till I tested the application in Russian, with
Unicode encoding, and only the half site was received.
The use of CSS can carry some undesirable effects when using different browsers. That is
actually a problem that I had. See all the details in section 3.3.2.2.
107
Finally, to skin the applet I had to implement another method and try different solutions till it
worked properly. All the details about the internationalization and localization of it can be
read in section 3.3.2.7.
3.3.6
Advantages and disadvantages
This section outlines the advantages and disadvantages of using the proposed method for
the concrete application of FcB. For a general evaluation of the method in any web
application see the next section (3.4).
3.3.6.1 Advantages
FOR …
Siemens AG
ADVANTAGES
 Easy to offer it:
o
Small modifications in the java application
o
Creation of the template based on the original html sites that Siemens had
o
The customer will only need a good documentation about it
 Notable improvement of the web service without much effort
Provider
(Telco)
 Easy to customize the web applications they buy; it is in fact, one of the most
important advantages of this method, the easiness to achieve it. See section 3.3.3
to read what the provider must do and know to skin the FcB sites (time saving)
 If the template is used by many clients (call-centers) the amount of data to
maintain in the server could be smaller: a unique HTML template is valid for all of
them (space saving) although there must be a XML file for each
B-Client
(Call-Center)
 They become a customized and internationalized application and their end-users
EndCustomer
None
will always recognise their Corporate Identity
Table 3.3.5: Advantages of the proposed skinning method for FcB
108
3.3.6.2 Disadvantages
FOR …
DISVANTAGES
Siemens AG
 Time exposure: for the customization of the rest of the web services that
Siemens has, all the changes that have been done for FcB should be also
applied. The time exposure is however not extreme at all; on the contrary, this
method offers the possibility of being applied relatively quickly
 Loss of recognition: this, as well as the “time exposure” is also a disadvantage
of Skinning in general (see 2.1.8). The loss of recognition for Siemens here is not
a matter of the proposed method of skinning but a consequence of the
personalization of any application. I write it here, because it is so demonstrated
that the end-client will not know any more who is the developer of the service,
which can be sometimes an advantage but also a disadvantage
 Complexity: it was another disadvantage of Skinning but I think here it is not
relevant at all, as it was seen when the method has been described
Provider
(Telco)
 None
B-Client
(Call-Center)
 None
End-
 Slower because of the whole process of customization (read XML file, read
Customer
template, customize it by inserting the content). See Table 3.3.3 for viewing the
measured times
 Loss of expressiveness: not every layout is achievable with this method (see
section 3.3.4.2, where the limitations are described). These disadvantages (time
requirements + expressivity) are actually proper of Skinning (see the
disadvantages of Skinning in section 2.1.8)
Table 3.3.6: Disadvantages of the proposed skinning method for FcB
3 Evaluation and appliance of Skinning at an existing : Conclusion
3.4
109
Conclusion and evaluation
In this final section of Chapter 3, a brief evaluation of the solution in general will be written. I
will consider again here the proposed method to skin FcB web application, but as a general
Skinning Technique for any web application, which is actually one of the most important
aspects of this diploma thesis, as its title (Skinning technique in Web Applications) already
suggests.
What is significant to take into account in the evaluation is whether this method could be
applied in any other web application, how difficult would it be, for which applications would it
be most suitable, etc.
First of all, the principle of the proposed method is very flexible and therefore it can be used
and applied in many situations. Since the point of view of its independence of platform, the
flexibility is always guaranteed. Besides, it should not be considered as a totally java-based
method, because other programming languages could implement the same functionality as
java here does. It must be taken from the proposed method only the general idea of
implementing the following elements:
-
Template (it must not be HTML) that suits for all customers
-
Data file that contains the data to customize the template
(XML is a good
alternative to do it, but not the only one)
-
Controller, which could be implemented with any programming language (C,
C++, Java, etc)
With the previous three points it is already demonstrated that the basic idea of the proposed
method is actually the appliance of the MVC (Model-View-Controller) design pattern. It is
very difficult, if not impossible, to skin an application when the data and the view are mixed.
Extending the concept to other type of utilities, such as applications on PC, the idea persists
equally suitable and could be used to customize many other cases. Some modifications
should always be done, to particularize the solution for different software, but the base
should be always the same.
My conclusion to this chapter is that Skinning may be achieved with many alternatives, but all
of them should have a concept in common, which is applying the MVC-model.
4 Conclusion and Achievements of the thesis: Summary of the master thesis
110
4 Conclusion and Achievements of the thesis
Outline: This chapter presents a summary of the whole content of the master thesis,
together with the exposition of all achieved results during the time of research and work, and
also a subchapter with all the possible points of extension about the topics that were handled
along the whole document.
4.1
Summary of the master thesis
The main points and conclusions of the whole master thesis are again in this section
mentioned and summarized. This will be actually the subchapter, where all the statements
about my master thesis are presented and reasoned.
From the theoretical research about Skinning the following aspects have been concluded
(see List 4.1.1 for a schematic representation of them and read the next paragraphs for a
more detailed description of them).
Skinning is a relatively recent issue that makes it possible to change automatically the whole
layout of a software application. Where Skinning takes place, Skins and Themes are also
necessary. These two words refer to all those elements that compound a skinnable user
interface, such as logos, images, colours, buttons, slide bars, etc. There is a small difference
between Skins and Themes, but in general terms, since the point of view of functionality,
they can be even replaceable with each other.
The technique of Skinning has two different areas of application that depend basically on
where it takes place, that is, between the provider and a business customer (B2B) or
between a business part and the end-customer (B2C). However, the most extended one is
the one that takes place at the end-user side. The most popular skinnable programs are
those in which the end-user can easily personalize his/her user interface with the use of the
existing Skins in Internet or even creating him/herself his/her own Skins, with the help of
“how-to” tutorials. This area of application has made of Skinning a well-known and
fashionable technique, which is considered by the end-user as a desirable characteristic for
the software he/she uses. So it is, that the best known functionality of Skinning till now is the
111
one oriented to the enjoyment of the end-users when they design their own layouts for their
favourite skinnable programs. There is actually a lot of information about the Skinning of
these applications in the Web (tutorials, thousands of Skins to download and install, last
news about new Skins or skinnable software…).

Skinning is an up-to-date technique that makes it possible to change the layout of
GUI automatically

Skins and Themes are the customizable elements in the GUI

The technique of Skinning has two areas of application: Provider- (B2B) and User(B2C) area

Skinning is mostly known because of its B2C-area of application, while the B2Barea is practically new

There are lots of skinnable programs, where end-users can change their GUIs in
a simple way, but the methods that these programs utilize are not so clear

A proper way to achieve Skinnability is the use of the Model-View-Controller
design pattern, where content and presentation of the application must be dealt
separately

There are no standards related to Skinning and only three patents have been
found (June 2003) about the topic

Skinning has also limitations: not every application can be skinned, and not every
element in the GUI of an application can be skinned

Many of the presented skinning methods make however use of web standards
(XML, CSS…) which makes of Skinning a platform-independent technique in those
cases

A set of skinning tools exists already on the market, but not enough to have the
possibility of choice
 Skinning can be an easy way to achieve customization and internationalization
List 4.1.1: Summary points of theory about Skinning
of applications
On the contrary, there is almost nothing written about the methods that these programs use
to become skinnable. Therefore one of the objectives for the master thesis was actually to
make a research about which methods could be applied when creating an own skinnable
software application. A classification of some skinning methods and an overview of the
existing commercial skinning tools have been even exposed in the thesis. All these methods
and some of the tools are based on a design pattern, known as the Model-View-Controller
model. It consists on separating the data of content (Model) from the presentation (View) and
having a third element (Controller) to make the union between the other two. This idea has
112
been also taken into account in the practical part of the diploma thesis, when implementing a
skinning method for a certain web application.
Once that the technique of Skinning has been introduced, the reader may ask him/herself
what can really be achieved with this technique; I must unfortunately write that not everything
can be skinned in the UI of an application. Which it is more, Skinning can even provoke a
loose of expressiveness in the UI where it is applied. Other disadvantages of this technique
are that the software may become slower when it is modified to be skinnable, and since the
point of view of the implementation, it costs time and effort for the developers when they
must create a skinnable application. The main reason of resulting sometimes complicate to
implement skinnable software is the lack of standards and research about this technique.
This was actually one of the main points of motivation of choosing this topic for a master
thesis.
Nevertheless, not only disadvantages should be here mentioned; the process of Skinning
has also enough important advantages to be here again cited, especially related to those, not
so well known functionalities that are typical of the technique of Skinning. More about the
new area of application of Skinning must be then written, which takes place between provider
and business-customer (B2B), and whose objectives are often to offer the customization,
internationalization and localization of the software application. These three words, together
with the personalization of an application, have been more than once used along this
document. Skinning can in some terms make it possible to create customizable and
internationalizable applications, which implies a new functionality to be considered also as an
advantage. Since this point of view, Skinning is not more only a way that end-users have to
enjoy themselves creating different layouts for their programs, but also a possible way to
customize and internationalize an application.
Below, the summary of the practical work will be presented. See List 4.1.2 for a schematic
view of the points related to the practice and read the following paragraphs for a more
detailed description.
In the Industry Example presented in the practical part of the master thesis, the technique of
Skinning has been applied for a certain web application. The proposed skinning method to
use with one of the web services of Siemens was firstly mentioned in the theoretical study
and then carried into the practice. It consists in separating the content and the view of the
web application following the MVC-pattern, and creating the controller with the programming
language in which the application has been programmed. This general skinning method,
113
based on a template, a content file (e.g. a XML file) and a controller implemented with the
main programming language of the application, can be easily extended and particularized for
many different web applications and also software on PC.

Appliance of Skinning in a certain web application of Siemens to achieve the
customization and internationalization of it

The Industry Example of Siemens pertains to the “Provider”-area of application.
There are actually in this example two B2B areas of application

The whole application of Siemens, called Free-Call-Button had to be studied in
order to find the most suitable skinning method for its characteristics

The proposed method is based on the MVC design pattern: XML file (Model),
HTML Template with CSS (View) and Java Servlet (Controller)

For each customer, a different layout and language can be chosen automatically
(Skinning)

Evaluation and optimizations of the first proposed method till the definitive one
was achieved, have been also an important part of the practical work

Other alternatives for the Model component within the MVC pattern have been
also proposed and tested

The method used to skin the applet in the application for example, was a bit
different than the one utilized for the rest of the application: the Model component
for the applet was a properties file, making use of a certain java class

The use of CSS implies problems with the support of browsers: The more the UI
depends on CSS, the more differences there are between the different browsers

The internationalization of the application was one of the most interesting
matters to be solved and also one of the most problematic, because of the
encoding of the texts and the newness of it
List 4.1.2: Summary points of the practical work
What I had to do with the web service of Siemens is actually applying this idea, but for the
characteristics of the application in particular, that is, as the web pages were based in HTML,
the template, which is part of the view within the MVC model, had to be also in HTML; as the
main programming language was Java, it is clear that the controller had to be implemented
also in Java; finally, for the content, it was first presented a XML file with the functionality of a
properties file, but other alternatives, making use of some java classes were also presented
to improve the performance of the application.
114
In this Industry Example of Siemens, the “Provider-area” of application (B2B) of Skinning was
put into practice, and also some of the new functionalities of Skinning have been with it
demonstrated. The objective with the web service of Siemens was not to offer the end-users
the possibility of changing the layout of their GUI, but more to achieve the customization and
internationalization of the application to be offered to different business customers in different
countries, who wanted to maintain their Corporate Identity and language in the layout of the
web application that they would offer to their own also business customers.
To the practical work corresponds also the evaluation of the first proposed method, followed
by the optimization of it. The very first method was not exactly the same as the final and
definitive one. The general idea of separating content and presentation was since the
beginning, but some modifications had to be done along the time of work in order to achieve
a proper solution, since the point of view of the performance of the web service.
It was firstly thought, for example, to use only a XML file for all customers, which had very
bad consequences in the performance, because the application became too slow, due to the
management of a XML file of large size and the algorithm of search in the XML file for each
customer.
In definitive, not only proposing and applying the Skinning method was part of the practical
work, but also analyzing the whole web application of Siemens, learning its functionality, the
development process and finally searching for the most suitable and optimum skinning
method.
Finally, the conclusion of the practice for future works and appliance of Skinning is that, when
creating a new skinnable application, the content and the view should be considered
separately and a third element should play the role of controlling the junction between both of
them. The application in particular must be studied in order to decide which element will play
each role within the proposed solution. Nothing is fixed; nothing is marked to be in a certain
way, but only the separation between presentation and content.
4 Conclusion and Achievements of the thesis: Achieved results
4.2
115
Achieved results
This subchapter outlines all achieved results from the expected ones at the beginning of the
master thesis, which were already listed in section 1.4.
The following tables show again the list of results that should have been achieved, together
with the check if they were achieved or not. In those cases in which they were not achieved,
a couple of comments are written.
From the theory, it was expected …
Achieved?
 Complete exposition of the topic of Skinning with the categorisation of
all the found information: it is expected that any reader of the master
thesis becomes the information that he/she may need about Skinning
√
(features, applications, advantages and disadvantages, boundary
conditions, etc)
 Exposition of different skinning methods classified by different criteria
and described in full detail
 Overview of existing skinning tools on the market and description of
their main features and functionality
 Suggestion of a suitable method/tool to be applied in the Industry
Example of Siemens
From the practical work, it was expected …
 The presentation of a method/tool that is able to skin any web
application
 Use of this method in a certain Web Service of Siemens and its
evaluation
√
√
√
Achieved?
√
√
 Customization and Personalization of the Web Service with the use of
the implemented method: it is expected that the web application to
√
work with becomes skinnable
 Internationalization and Localization of the web service with the use of
the implemented method: it is expected that the web application can be
√
adapted to any country
 Installation and production of the new version of software, with the
proper documentation about it
(It will be
done)
Table 4.2.1: Achieved results in the master thesis
4 Conclusion and Achievements of the thesis: Achieved results
116
As it has been exposed in the table (Table 4.2.1) all the expected results for the master
thesis have been achieved, and only the installation and new production of the web service
has not been done yet. The reason of having waited to do it, and not having included it in the
master thesis, has more to do with organizational matters than with the master thesis itself.
Moreover, some other results that had not been expected have been also achieved (see List
4.2.1):

Introduction to the topic internationalization and review of the new methods of
java to achieve it

Report of all those points to take into account when different languages come into
play in an application

Best skinning method to customize also the applets of web applications

Outline of the problems that the use of CSS may cause with browsers

Overview of the customization of the error sites with Apache
List 4.2.1: Achieved results that had not been expected
All these points have been concluded from the research work or from the problems that were
found during the practice.
4 Conclusion and Achievements of the thesis: Possible points of extension
4.3
117
Possible points of extension
This last subchapter will present the possible points of extension of the current master thesis.
Due to the newness of the technique of Skinning, it can be written that there is still much to
do in the world of Skins and Themes.
In the master thesis many aspects of this technique have been handled and almost each of
them could be a matter of research in the following years, since Skinning is a developing
technique that will be make great progress in the very near future.
There are actually three directions in which the points of extension can be oriented:

Research of the same topics that have been here handled because of the possibility
of its extension in the near future
o
Looking for new skinnable programs on the market and the methods they use
o
Looking for new skinning tools on the market
o
Looking for new skinning methods or new documentation about the already
existing ones
o
Looking for software developer companies that begin to offer customizable
and internationalizable applications with the appliance of Skinning
o
Looking for new patents
o
With this new information, a more complete document similar to the present
one could be rewritten

Extend those topics that were already handled in the master thesis but in more detail.
The next list present all these topics in order of importance (from the most interesting
one to the least one):
o
Internationalization and localization of SW are two words that were more than
once mentioned along this master thesis. There is still much to do about these
topics and both terms are more and more important since companies desire to
go on to international markets. The technique of Skinning has been here used
in order to achieve them has been here used, but not widely enough.
Research about these concepts should be one of the points of maximum
interest in the possible extension of this thesis. Questions such as, how to do
it with other programming languages different to java, how to create
4 Conclusion and Achievements of the thesis: Possible points of extension
118
localizable Skins/Themes, how to create a localizable UI with the use of
Skins/Themes, should be answered in future works
o
Try to implement new web applications, instead of working with an existing
one and use some of the skinnable frameworks presented in this master
thesis. For example, for applications with java, there are two possible ones:
Struts and Pajes. Both of them separate the content from the presentation of
the application and give the possibility of creating skinnable web applications
with java
o
The introduction of XML to define the UI will be, in my opinion, the future of
customizable applications. The use of a web standard like XML makes it
easier to create UI independent from platforms. For example, XUL (Language
based on XML to define UI, created and used by the browser Mozilla) could
be a solution to define the future UI in any application. This is also a possible
point of extension: try to use XUL in an Industry Example. There are already
some developing projects that use XUL in their UI. See information about XUL
in section 5.3.1,reference [3.3]

Since the point of view of the particular Industry Example of Siemens, some things must
be still done. They are of course not so relevant for other research works about Skinning,
although some conclusions could be anyway taken from:
o
The way the awt elements of an applet could be customized (skinned): resizing
when the text needs more space, etc
o
Replace of CSS with another style element that provokes no problems with the
browsers
o
Optimization of the proposed skinning method for the practice, since the point of
view of the performance
The previous points of extension corroborate again the newness of this technique, together
with its importance within the development of new software applications. There is still much
to do in the world of Skinning, and therefore, it should be no more considered only as an
enjoyment of end-users, but as a developing technique that has much to offer to the future of
customizable software on the market.
5 General Information: Abbreviations
119
5 General Information
Outline: In this chapter the general information of the master thesis is presented. Glossary,
abbreviations and references complement its content.
5.1
Abbreviations
Ads: Active Directory Server
MPL: Mozilla Public License
ASP: Active Server Pages
MVC: Model View Controller
ASP.NET: Active Server Pages .NET
Nds: Novell Directory Service
ATL: Active Template Library
OS: Operating System
B2B: Business to Business
PHP: Hypertext Pre-processor
B2C: Business to Customer
RDF: Resource Description Framework
CGI: Common Gateway Interface
SAP: Software Application Provider
CMS: Content Management System
STL: Standard Template Library
COM: Component Object Model
WYSIWYG: What You See Is What You Get
CSS: Cascade Style Sheets
XHTML: Extensible Hypertext Markup Language
CWS: Click-to-Dial Web Server
XML: Extensible Markup Language
FcB: Free Call Button
XSL: Extensible Style sheet Language
GPL: General Public License
XSLT: Extensible Stylesheet Language Transformation
GTK: Gimp Tool Kit
XUL: Extensible User-interface Language
GUI: Graphical User Interface
IDE: Integrated Development Environment
i18n: Internationalization
IPAS-BUS: Intellectual Property Application System - Business Unit Services
JFC: Java Foundation Classes
JSP: Java Server Pages
KDE: K Desktop Environment
l10n: Localization
MFC: Microsoft Foundation Classes
5 General Information: Glossary
5.2
120
Glossary
Active X: A loosely defined set of technologies developed by Microsoft. ActiveX is an outgrowth of two
other Microsoft technologies called OLE (Object Linking and Embedding) and COM (Component
Object Model). As a moniker, ActiveX can be very confusing because it applies to a whole set of
COM-based technologies. Most people, however, think only of ActiveX controls, which represent a
specific way of implementing ActiveX technologies.
(Source: http://www.webopedia.com/TERM/A/ActiveX.html)
Active X controls: A control using ActiveX technologies. An ActiveX control can be automatically
downloaded and executed by a web browser. ActiveX is not a programming language, but rather a set
of rules for how applications should share information. Programmers can develop ActiveX controls in a
variety of languages, including C, C++, Visual Basic, and Java. An ActiveX control is similar to a Java
applet. Unlike Java applets, however, ActiveX controls have full access to the Windows operating
system. This gives them much more power than Java applets, but with this power comes a certain risk
that the applet may damage software or data on your machine. To control this risk, Microsoft
developed a registration system so that browsers can identify and authenticate an ActiveX control
before downloading it. Another difference between Java applets and ActiveX controls is that Java
applets can be written to run on all platforms, whereas ActiveX controls are currently limited to
Windows environments. (Source: http://www.webopedia.com/TERM/A/ActiveX_control.html)
Branding (look and feel): It means in the scope of Customization all that represents the identity of a
Company. Sounds, colors, graphics, icons, or also special handling (e.g. a way of login) may form an
identity and belongs to branding related material. (Source: SIEMENS intern: SURPASS Products,
Description P30309-A0077-A321-04-7618, “Adaptations for MMA Customer Projects Guideline”)
Build-in class (in java): It is a class whose instances have restricted capabilities or special
representations. (Source: http://www.franz.com/support/documentation/6.2/ansicl/dictentr/built-in.htm)
Business Logic: The code that implements the functionality or business rules of an application.
(Source: http://java.about.com/library/glossary/bldef-buslogic.htm)
Content Management: The management of all the data that an application may contain.
Configuration: It means in the scope of Customization the adaptation of information in order to fit an
application to the need of a customer (e.g. special numbers like the country code). (Source: SIEMENS
intern: SURPASS Products, Description P30309-A0077-A321-04-7618, “Adaptations for MMA
Customer Projects Guideline”)
Cookies: Cookies are pieces of information generated by a Web server and stored in the user's
computer, ready for future access. Cookies are embedded in the HTML information flowing back and
121
forth between the user's computer and the servers. The main purpose of cookies is to identify users
and possibly prepare customized Web pages for them. When you enter a Web site using cookies, you
may be asked to fill out a form providing such information as your name and interests. This information
is packaged into a cookie and sent to your Web browser, which stores it for later use. The next time
you go to the same Web site, your browser will send the cookie to the web server. The server can use
this information to present you with custom web pages. So, for example, instead of seeing just a
generic welcome page you might see a welcome page with your name on it.
(Source: http://www.cookiecentral.com/content.phtml?area=2&id=1,
http://www.webopedia.com/TERM/c/cookie.html)
Corporate Identity: The consistent image created by a company's offline and online communications.
This image usually consists of: consistent use of specified colors, typefaces, graphics, layout and logo.
(Source: http://www.templatecentral.com/newsletters/corpidglossary.asp)
Customization: Adaptation of the existing application to the needs of the customer. It is subdivided in
to the following topics: Branding, Configuration, (Sub-) Functions. (Source: SIEMENS intern:
SURPASS Products, Description P30309-A0077-A321-04-7618, “Adaptations for MMA Customer
Projects Guideline”)
HTMLB controls: HTMLB (HTML-Business for Java) provides a full set of easy-to-use Web controls.
These guidelines describe the HTMLB controls, their types, usage, attributes, and how to set the
attributes with the JSP-taglib and the classlib. For each control there is a general page that describes
its usage, types, and design-relevant attributes. This description is on the interaction design level. A
further page describes more technical issues, such as browser compatibility, edit-ability in the Style
Editor, and accessibility issues. Thirdly, the Control API page provides a development-oriented view of
the control with detailed descriptions of attributes and parameters. In addition, there are pages that
describe general interaction design aspects, such as page layout, correct usage of certain often-used
controls, as well as hints on finding the right control for a given purpose.
(Source: http://sapdesignguild.org/resources/htmlb_guidance/getting_started.html)
Industry Example: A practical and real example implemented for any company.
Internationalization: It describes how to design an application in a way that country dependent parts
can be easily adapted later on. It facilitates the later executed modification of the final (pre-)product to
local target markets. (Source: SIEMENS intern: SURPASS Products, Description P30309-A0077A321-04-7618, “Adaptations for MMA Customer Projects Guideline”)
Localization: Project specific adaptation of an application to specific needs of a given country/region.
It applies the mechanisms of Internationalization. (Source: SIEMENS intern: SURPASS Products,
Description P30309-A0077-A321-04-7618, “Adaptations for MMA Customer Projects Guideline”)
122
MMX technology: It is a technology designed expressly to improve the performance of image
processing and graphics. This technology dramatically enhances image processing operations such
as alpha blending and blurring, resulting in performance that is 2-to-4 times faster than conventional
Intel processors. Furthermore, this technology is relatively universal; although MMX is not generally
found in chip sets that are not made by Intel, competing processors such as the power PC use similar
processing instructions capable of displaying SUI (Skin User Interfaces) at no extra cost to the user.
(Source: http://www.supelec-rennes.fr/ren/fi/elec/ftp/docs/mmx/mmx_overview.pdf)
Personalization: It means the adjustment of possible options, e.g. color schemes, tones and so on, to
personal habits. Only foreseen options can be personalized und, in contrast to Customization, it will be
executed during runtime of an application at the target environment (e.g. end user PC or in Browser at
end user PC), and performed by end user, not by developer or vendor of a product. (Source:
SIEMENS intern: SURPASS Products, Description P30309-A0077-A321-04-7618, “Adaptations for
MMA Customer Projects Guideline”)
Plug-In: Plug-ins are software programs that extend the capabilities of one browser in a specific way giving, for example, the ability to play audio samples or view video movies from within the browser.
(Software: http://wp.netscape.com/plugins/?cp=dowdep2)
Presentation Management: all code of an application that refers to the layout and view of it.
Sablotron: It is a fast GPL or MPL licensed XSLT engine fully implemented in C++. It is an Open
Source Toolkit for XML. For the programming languages Perl, PHP, Python, Object Pascal, Ruby,
Erlang, Tcl and Ada there are Wrappers that make it possible to use Sablotron with this languages.
(Source: http://genomenews.free.fr/tutorials/sablot.html)
Server Controls (ASP.NET): Server controls are tags that are understood by the server. There are
three kinds of server controls: HTML Server Controls (Traditional HTML tags), Web Server Controls
(New ASP .NET tags), Validation Server Controls (For input validation). With Classic ASP it is
impossible to separate executable code from the HTML itself. This makes the page difficult to read,
and difficult to maintain. ASP .NET has solved this problem with server controls.
(Source: http://www.w3schools.com/aspnet/aspnet_controls.asp)
Servlet: A Java program, which resides and executes on a server to provide functionality to the server
or processing of data on the server. (Source: http://www.learnthat.com/define/s/servlet.shtml)
Skin: It is the set of elements that includes everything necessary to change the “look and feel “ of a
particular GUI of a certain application. They could include bitmaps for each element in the layout of the
application (buttons, title bars, sliders, radio buttons, check boxes, borders…). The process of
Skinning consists actually in replacing any of these Skins with another one or just adding and
eliminating Skins from the layout to show a completely different GUI. They allow the user to configure
the GUI by choosing different categories of Skins.
123
Skinning: It is the technique that makes it possible to modify automatically the complete layout of a
software application. This means that each user of the application can choose a different GUI at
runtime or that the developer him/herself can change the appearance of his/her program without
having to add any line of code.
Template Engine: Any tool/means/element/program that allows separating business logic from layout
when coding an application.
Template Technology: Any technology that makes use of templates: a template is a document or file
having a preset format, used as a starting point for a particular application so that the format does not
have to be recreated each time it is used.
Themes: Set of elements, but they consist in individual files, which are usually ordered in directories.
They are used for general things above the operating system layer (for example: the color-patterns of
operating systems, background images, etc). On the contrary, Skins are usually created even for a
certain program and they can mostly only work properly with it.
WebMacro: WebMacro is a 100% Java open-source template language that enables programmers
and designers to work together while promoting the ModelViewController pattern. WebMacro is a
viable alternative to JavaServerPages, PHP, and ASP. It's the fundamental page technology behind
several major websites such as Altavista. WebMacro separates concerns about program code from
concerns about the way a page looks: HTML should not clutter up program code, program code
should not clutter up HTML. (Source: http://www.webmacro.org/)
Wrappers: Wrappers are a type of software "glueware" that is used to attach together other software
components. A wrapper encapsulates a single data source to make it usable in a more convenient
fashion than the original unwrapped source; this distinguishes wrappers from another kind of glueware, mediators that combine data from different data sources. Wrappers are assumed to be "simple",
although there is no clear demarcation between what belongs in a "simple" wrapper and a "complex"
higher level component. Wrappers can be used to present a simplified interface, to encapsulate
diverse sources so that they all present a common interface, to add functionality to the data source, or
to expose some of the data source's internal interfaces.
(Source: http://www.objs.com/survey/wrap.htm)
WYSIWYG: Editor or program that allows an interface or content developer to create a graphical user
interface or page of text so that the developer can see what the end result will look like while the
interface or document is being created. A WYSIWYG editor can be contrasted with more traditional
editors that require the developer to enter descriptive codes (or markup) and do not permit an
immediate way to see the results of the markup.
(Source: http://whatis.techtarget.com/definition/0,,sid9_gci213392,00.html)
5 General Information: References
5.3
References
5.3.1
[1]
124
Links
Most important Skinning Sites
[1.1] http://www.customize.org
[1.2] http://www.deskmod.com
[1.3] http://www.deviantart.com
[1.4] http://www.lotsofskins.com
[1.5] http://www.skinbase.org
[1.6] http://www.skinz.org
[1.7] http://www.velocityart.com
[1.8] http://www.wincustomize.com
[2]
Skinning Methods
[2.1] http://www.domesticat.net/skins/howto.php
[2.2] http://www.feenysfunhouse.com/journal/archives/jasons_thoughts/000128.html
[2.3] http://www.oreillynet.com/pub/a/javascript/2001/04/27/essential_js.html?page=1
[2.4] http://feeny.verberweb.com/journal/archives/jasons_thoughts/000128.html
[2.5] http://www.snazzykat.com/archives/002623.php
[2.6] http://www.deliriouscool.org/archives/cat_weblog_widgets.php
[2.7] http://www.mozilla.org/docs/ora-oss2000/skins/index.htm
[2.8] http://www.winamp.com/
[2.9] http://msdn.microsoft.com/msdnmag/issues/03/03/SiteSkinning/default.aspx
[2.10] http://www.westciv.com/style_master/academy/browser_support/
[3]
XML and XUL
[3.1] http://www.oreillynet.com/pub/a/network/2000/04/28/feature/xul-xml.html?page=1
[3.2] http://www.xmlsoft.org/
[3.3] http://www.xulplanet.com/tutorials/xultu/intro.html
[4]
Additional Skinning Sites:
[4.1] http://www.ezskins.com
[4.2] http://www.anyskins.com/faq.html
[4.3] http://www.giggle.de/faq.php
[4.4] http://www.gillsthemes.fsnet.co.uk/faq.htm
[4.5] http://www.xp-styles.de, http://www.style-xp.com
[4.6] http://www.themes.org
[4.7] http://www.screensandthemes.com/
125
[4.8] http://www.themesunlimited.com/
[4.9] http://www.freethemes.com/
[4.10] http://www.wm.themes.org/
[4.11] http://www.kde.themes.org/
[4.12] http://freshmeat.net/
[4.13] http://www.themeworld.com/
[4.14] http://www.gtk.themes.org/
[4.15] http://www.topthemes.com/
[4.16] http://www.invisionskins.com/index.php?p=skinguide&cat=templates
[5]
Products:
[5.1] http://www.enterprisecustomization.com/ASPNET1.htm
[5.2] http://www.devexpress.com
[5.3] http://www.ingenuware.com
[5.4] http://www.l2fprod.com
[5.5] http://www.pajes.org
[5.6] http://www.codeproject.com/dialog/skinstyle.aspserver33.hypermart.net/celibol/skinsys.htm
[5.7] http://www.softshape.com/activeskin
[5.8] http://www.stardock.com
[5.9] http://www.xheo.com/products/webskin/
[5.10] http://www.skinux.com/technology.php#applications
[5.11] http://www.skinux.com/technology.php
[5.12] http://www.actionframework.org/
[5.13] http://www.smartbrainsoftware.com/Smart%20Brain%20Software_Fles/SkinBoxer.htm#top
[5.14] http://www.windowblinds.net/skinning/
[5.15] http://www.codeproject.com/dialog/ezskin.asp
[5.16] http://www.exontrol.com/sg.jsp?content=products/exskin
[5.17] http://www.tmssoftware.com/tsf.htm
[5.18] http://www.vbaccelerator.com/codelib/gfx/skin.htm
[5.19] http://www.netbeans.org/kb/articles/skin-old.html
[5.20] http://xreporter.cocoondev.org/index.html
[5.21] http://www.theskinsfactory.com/skinsfactory/?page=wd
[5.22] http://sapdesignguild.org/editions/edition6/theme_editor.asp
[5.23] http://www.stardock.com/products/directskin/
[6]
Programs with Skinning support:
[6.1] http://sonique.lycos.com/
[6.2] http://drweb.de/browser/netscape6_themes.shtml
[6.3] http://www.linux-magazin.de/Artikel/ausgabe/2000/10/KDE/kde.html
126
[6.4] http://wp.netscape.com/eng/mozilla/ns6/themes/creating.htm
[6.5] http://themes.mozdev.org/
[6.6] http://community.borland.com/article/0,1410,28423,00.html
[6.7] http://www.smbessentials.com/link_directory/index_skin.htm
[6.8] http://delphi.about.com/cs/toppicks/tp/aatpxpthemes.htm
[7]
Separate Model from Content and MVC links
[7.1] http://www.object-arts.com/EducationCentre/Overviews/MVC.htm
[7.2] http://ootips.org/mvc-pattern.html
[7.3] http://c2.com/cgi/wiki?ModelViewControllerAsAnAggregateDesignPattern
[7.4] http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
[7.5] http://javanook.tripod.com/patterns/java-mvc.html
[7.6] http://www.enode.com/x/markup/tutorial/mvc.html
[7.7] http://rd13doc.cern.ch/Atlas/Notes/004/Note004-7.html
[7.8] http://www.webmacro.org/
[7.9] http://jakarta.apache.org/velocity
[7.10] http://www.javaworld.com/javaworld/jw-04-1998/jw-04-howto.html
[8]
Java Skinning and Internationalization
[8.1] http://www.javaworld.com/javaworld/jw-05-2000/jw-0518-skins.html
[8.2] http://java.sun.com/docs/books/tutorial/i18n/resbundle/concept.html
[9]
Private skinnable websites examples
[9.1] http://acting-natural.com/
[9.2] http://astarael.net/
[9.3] http://blogblogbaby.com/
5.3.2
Literature
[10] Design Patterns, Elements of Reusable Object-Oriented Software
Author: Erich Gamma et al
Editorial: Addison Wesley
[11] Pattern Oriented Software Architecture: A System of Patterns
Author: Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad (contains
detailed description of MVC, and also of a related architecture: Presentation-AbstractionControl)
5 General Information: List of figures, tables
5.4
5.4.1
127
List of figures, tables and lists
Figures
Figure 2.1.1: Representation of the MVC design pattern............................................................... 18
Figure 2.1.2: Mode of operation of the MVC design pattern ......................................................... 19
Figure 2.1.3: Normal aspect of Winamp .......................................................................................... 22
Figure 2.1.4: One of the thousand existing Skins for Winamp....................................................... 22
Figure 2.1.5: Graphical example of Skins in Winamp.................................................................... 22
Figure 2.1.6: Representation of B2B and B2C relations................................................................. 27
Figure 2.2.1: Representation of skinning method 1 (XML + HTML/CSS + Java servlet) ........... 38
Figure 2.2.2: Flow diagram of skinning method 2 (php/asp with CSS)......................................... 39
Figure 2.2.3: Transformation of XSL files in (X)HTML to be viewed in a browser .................... 41
Figure 2.2.4: Example of XML file that makes references to the existing skins ........................... 43
Figure 2.2.5: Example of properties file in java skin method......................................................... 46
Figure 2.2.6: Layout 1 (Java Skins).................................................................................................. 46
Figure 2.2.7: Layout 2 (Java Skins).................................................................................................. 46
Figure 3.2.1: Areas of Application particularized for Free Call Button Web Application .......... 58
Figure 3.2.2: Site of the Call-Center with the FcB-button (menuhaut.htm) ................................. 61
Figure 3.2.3: FreeCallButton page (call_callId.htm) ...................................................................... 61
Figure 3.2.4: Site calendar.htm......................................................................................................... 61
Figure 3.2.5: Site error_callId.htm................................................................................................... 62
Figure 3.2.6: Site notificationviewer.htm......................................................................................... 62
Figure 3.2.7: Architecture 1 of FcB.................................................................................................. 63
Figure 3.3.1: Considerations to propose a solution to skin the FcB application ........................... 67
Figure 3.3.2: MVC- model in the solution for FcB.......................................................................... 69
Figure 3.3.3: Flow diagram of the solution...................................................................................... 71
Figure 3.3.4: Example of CSS file and respective HTML code lines ............................................. 73
Figure 3.3.5: Example of the XML File ........................................................................................... 76
Figure 3.3.6: Description of the servlet in FcB ................................................................................ 86
Figure 3.3.7: Description of the FcB servlet in the normal functionality of the app..................... 87
Figure 3.3.8: Description of the FcB Servlet when the app. has been skinned.............................. 89
Figure 3.3.9: Web Pages of Siemens style ........................................................................................ 92
Figure 3.3.10: Skinned FcB (Style 1)................................................................................................ 93
128
Figure 3.3.13: MVC-Model when skinning the applet.................................................................... 95
Figure 3.3.14: Examples of the skinned applet .............................................................................. 100
Figure 3.3.15: View of the template.html without being customized ........................................... 105
Figure 6.1.1: MVC in tool Xheo.WebSkin ..................................................................................... 131
Figure 6.1.2: Development process of WebSkin tool..................................................................... 133
Figure 6.1.3: Creation of the HTML page with WebSkin ............................................................ 134
Figure 6.1.4: The MessageBox is not skinned................................................................................ 136
Figure 6.1.5: The MessageBox is here skinned, thank to SkinBoxer ........................................... 136
Figure 6.1.6: DirectSkin Tool
(source: section 5.3.1 reference [5.23]) ............................... 138
Figure 6.1.7: MVC in tool Skinux .................................................................................................. 141
Figure 6.1.8: MVC pattern in tool ActionServlet .......................................................................... 143
Figure 6.1.9: Folder hierarchy in themepack.zip .......................................................................... 144
Figure 6.1.10: Tool PAJES, separation of content and presentation management .................... 145
Figure 6.1.11: Example of mySAP Portal with logo of SAP ......................................................... 148
Figure 6.1.12: Example of mySAP Portal with custom logo......................................................... 149
5.4.2
Tables
Table 2.1.1: Examples of Skins and Themes.................................................................................... 24
Table 2.1.2: Advantages of the use of Skinning............................................................................... 31
Table 2.1.3: Disadvantages of the use of Skinning .......................................................................... 32
Table 2.2.1: Classification of skinning methods .............................................................................. 36
Table 2.2.2: Advantages and disadvantages of the skinning methods ........................................... 48
Table 2.3.1: Overview of skinning tools that depend on Microsoft................................................ 52
Table 2.3.2: Overview of platform independent skinning tools (C++/Delphi) .............................. 53
Table 2.3.3: Overview of platform independent skinning tools (Java) .......................................... 53
Table 2.3.4: Overview of platform independent skinning tools (Visual Basic) ............................. 53
Table 2.3.5: Overview of other tools (application dependent)........................................................ 54
Table 3.2.1: Technical characteristics of Free-Call-Button............................................................ 60
Table 3.3.1: Elements to replace with markers and other characteristics of the template........... 72
Table 3.3.2: Obtained times in the search of the callId along the XML file .................................. 77
Table 3.3.3: Measured times of the customization of the template ................................................ 79
Table 3.3.4: Examples to name the properties files of the callIds .................................................. 84
Table 3.3.5: Advantages of the proposed skinning method for FcB ............................................ 107
129
Table 3.3.6: Disadvantages of the proposed skinning method for FcB........................................ 108
Table 4.2.1: Achieved results in the master thesis......................................................................... 115
Table 6.1.1: Compatibility features of the product ExSkin.......................................................... 137
Table 6.1.2: Tools of ObjectDesktop .............................................................................................. 139
Table 6.1.3: Tools of WinCustomize .............................................................................................. 140
5.4.3
Lists
List 1.2.1: Reasons of interest in writing about Skinning ............................................................... 12
List 1.3.1: Summary of points of the State-of-the-Art of Skinning ................................................ 14
List 1.4.1: Expected results from the theoretical work ................................................................... 15
List 1.4.2: Expected results from the practical work ...................................................................... 15
List 2.1.1: Technical questions about the process of Skinning ....................................................... 25
List 3.3.1: HTML sites to be customized in FcB web application .................................................. 71
List 3.3.2: Interesting points when skinning the applet .................................................................. 99
List 3.3.3: List of problems and difficulties during the practical work ....................................... 105
List 4.1.1: Summary points of theory about Skinning .................................................................. 111
List 4.1.2: Summary points of the practical work......................................................................... 113
List 4.2.1: Achieved results that had not been expected ............................................................... 116
6 APPENDIX
130
6 APPENDIX
Outline: In the appendix some information about the commercial Skinning tools will be
presented.
6.1
6.1.1
Description of commercial tools
Introduction
There is a set of commercial tools in the world of Skins and Themes. The most important
ones were already presented in section 2.3 and they will be here in the appendix described
in more detail.
Nor all tools, neither all features here presented were tested because firstly, none of them
was suitable for the Industry Example of the practice and secondly, other points of the
master thesis were more important to dedicate more time with them.
So it is, many characteristics here written are exactly the same as the ones that can be found
in the respective web sites of these tools, in their user guides, tutorials, or any of their
documentation. Some of the descriptions are summaries or conclusions of all sources of
information. In any case, the links will be given, so that any interested reader in a certain tool
can find more about it.
It must be noticed, that in some tools the MVC model has been used for the implementation,
which remarks the idea that I already explained when exposing the skinning methods, that
the separation of the content from the presentation will always help to skin an application. In
those tools, in which this model has been used, I have described also which components
play the role of Model, View and Controller within the method.
I have not used the same structure to describe the tools because all the features that they
have in common have been already presented in tables in section 2.3. What it is going to be
shown in the appendix are more those specific characteristics that each of them has.
6 APPENDIX
6.1.2
131
MICROSOFT:
6.1.2.1 Xheo.WebSkin
It is a tool to create skinned ASP.NET websites. It is absolutely bound to ASP.NET and
works of course only with this platform. In order to explain the basis of this tool, it must be
written that the MVC-model will be here used. In the following picture, it is shown precisely
which components play the roles of content, model and view respectively.
Figure 6.1.1: MVC in tool Xheo.WebSkin
In order to understand the function of this tool, the technology ASP.NET should be known or
at least have a general idea about it. For example, a little knowledge of the existing
components, such as the server controls, or validators, is necessary to manage this tool.
What Xheo.WebSkin includes is a set of classes that can be summarized in the followings:
-
-
Page Templates: they define the general layout of a page

The Page Control

The Content Control

The XmlContent Control

The Target Control
Server Controls: they are one of the most important elements of the Skinning
engine. The server controls of ASP.NET have been modified so that they can
be skinnable. For example, a button control skin might render as an image, a
hyperlink or as standard HTML input button.
-
Validators: they have been also modified so that they can be skinned.
-
Free Controls: they are new controls that WebSkin offers.
6 APPENDIX
132
It separates content from design (MVC) and maintains a consistent look and feel across
the entire application. The content can be developed separately from the layout engine of the
site. It can be added to pages through a CMS (Content Management System), HTML or
custom content system. It could be also automatically imported from plain HTML files located
in the file system or from external URLs on another machine.
More interesting characteristics are (source: section 5.3.1 reference [5.9])

Multiple Layout Page Templates: From each web page developers can select
which template should be used to display the content on the page. It is possible to
provide multiple templates for different page styles, such as product listings, press
releases, administration, etc

Skinning of Common Controls (including DataGrid control): Many of the ASP.NET
server controls have been replicated as skinnable controls. Developers can alter the
look of buttons, validators, images, icons, tab strips, menus, page titles, page paths,
multi page views and more. Even input forms can be altered to achieve a different
look for each Skin through the use of section wrappers.

Design-time
Support: Support for skin
rendering
within
the design-time
environments of VisualStudio.NET and ASP.NET Web Matrix. All of the skinned
controls provide full design-time support providing semi-WYSIWYG support for
skinned controls. Content for the page templates can be edited directly in the editor
rather than requiring code level expertise as most template technologies require.

Browser Compatibility: You can provide downlevel and browser specific skins for
each skin control template and page template. The skin rendering engine
automatically detects the browser and uses the template that most closely matches
the profile

Dynamic Skin Selection: Skins can be selected either explicitly by the user
(B2C), or the developer can provide selection logic to provide skins based on various
criteria. For example, he/she can select the specific skins of his/her business
customer (B2B). It is possible to skin different portions of the application. It can be
even used as a marketing tool to skin product areas with a look and feel specific to
that product. A random skin could be selected per visit
6 APPENDIX

133
Based on XSLT, Server Controls and User Controls: Each page template is
contained within a UserControl (ASCX file). The page template defines target areas
for content that can be placed anywhere on the page. The skinned pages then define
content blocks that will be injected automatically into the template target areas. Each
of the skinned server controls (like the button and DataGrid) renders their visual
style from XSLT templates defined for each skin.
Figure 6.1.2: Development process of WebSkin tool

Visual "Inheritance”: Similar to Windows.Forms visual inheritance, skins that do not
define their own look and feel inherit from their parent skin. This allows developers to
easily create "sub-skins", or skin collections, that only make small visual changes,
like color or fonts, and leave the remaining styles the same.

Easy migration from current XML -> XSLT solutions: Using either the Generic
control or XmlContent, content transformations can be easily performed similar to the
current XSLT solutions. The Generic control and XmlContent make it possible to
specify an external XML source and perform transformations on that data with a
template unique to each skin.
6 APPENDIX
134
Figure 6.1.3: Creation of the HTML page with WebSkin

Add "Print This Page" Buttons with Print Skin: a printable version of the web
page is also possible: generally this has required the use of a CMS system with a
special template just for printing. Using a Print skin that has a stripped down page
template it is relatively ease to add a print button to the pages

More Information about the tool: section 5.3.1 reference [5.9]
6.1.2.2 ActiveSkin
It is an ActiveX control that allows the developers to dynamically change almost any aspect
of the visual appearance of their application (for use with: Microsoft Visual Basic 5-6, Borland
Delphi 3-6, Microsoft Visual C++ 5-6). In short, it provides full support to skin the application.
Summarized features from source section 5.3.1 reference [5.7]:

Use skin script language support and includes skins
6 APPENDIX

135
Full support for standard skins makes it possible to skin the entire application with a
single line call

Full support of translucent layered windows for soft shadows, glows or glass-like
effects

Powerful animation system, based on key-frame concept

Animated, interactive skins can be created entirely in SkinBuilder, without any
additional coding needed

Improved performance and reduced memory usage

Compiled skins, that can be built directly into executable

An easy to use yet powerful SkinBuilder application

Most of new SkinObjects can work both in windowed and windowless mode. For
example, SkinButton object is capable to skin the Button control, and be used as the
windowless Maximize Button for the SkinForm, or windowless "Play" button for
imaginary music player skin

A SkinForm object that represents a common window, with left, right, top and bottom
edges, non-client and client area, menu bar and popup menu settings.

Lots of new transitions and animated procedural texture effects

Powerful and easy to use key-frame animation technique, no more complicated
scripts are needed.

An open architecture, that enables to create the standalone SkinObjects.

Greatly improved performance and reduced memory usage.

A completely new SkinBuilder, that exploits new features of ActiveSkin to create a
really easy-to-use and powerful skin editor software.
6.1.2.3 Skinboxer
It is actually a complement to ActiveSkin that provides more facilities, such as Skinning also
the MessageBox, Open/Save dialogs, Browse for folder, ChooseFont, FindText, ReplaceText
in an application. Built as a COM object, it works pretty much as a plug-in to ActiveSkin. By
applying only a few lines of code SkinBoxer allows the developers to skin even the standard
common dialogs. The folllowing information and figures have been taken from source:
section 5.3.1 reference [5.13].
It intercepts the standard dialogs and replaces them with skinned dialogs. The code doesn't
need to change. Whether the application is programmed with VB and there is a call to
MsgBox or the used programming language is C++ and a call to MessageBox (or
AfxMessageBox from MFC) is required, SkinBoxer will find out and skin it. That means that
6 APPENDIX
136
even if the application calls functions from a DLL and the DLL pops up a common dialog box,
SkinBoxer will also intercept it and skin it. This means that basically the native calls
MessageBox, MsgBox, GetOpenFileName, etc) don't have to be changed Here is an
example of an application before and after applying SkinBoxer:
Figure 6.1.4: The MessageBox is not
Figure 6.1.5: The MessageBox is
skinned
here skinned, thank to SkinBoxer
(Source: section 5.3.1 reference [5.13])
(Source: section 5.3.1 reference [5.13])
Characteristics to mention in comparison to ActiveSkin (also source: section 5.3.1 reference
[5.13]):

Improved performance and reduced memory usage

Its most important components are presented below:
o
ISkinBoxer Interface: This interface derives from IDispatch. It is the interface
exposed by the SkinBoxer class and it is the only one that can be created
directly. All the other interfaces can be obtained from this class, calling
different methods
o
IskinObject: it will be used in the skinning process. The ISkinObject that is
passed here needs to be an ISkinForm object. This is the only ActiveSkin
object currently supported by SkinBoxer
o
Mask: it specifies what kind of common Window dialogs to skin (MessageBox,
Open dialog, Save dialog, etc)
o
Install: this method will install the SkinBoxer object in the current process,
allowing to skin the common dialog boxes
o
Uninstall: this method will uninstall the SkinBoxer object in the current
process. This will cause all the dialog boxes appearing unskinned.
6 APPENDIX

137
It is easy to use its SDK; How to apply SkinBoxer in an application:
o
Applying it on top of the application is quite simple. All that must be done is to
call the set of SkinObject that is to be used in the skinning process (once the
ActiveSkin form object is instantiated) and call the Install method.
6.1.2.4 EZSkin
It is a framework for building Skinnable UI’s for Microsoft Foundation Classes Apps. It
is by no means complete and presently only supports Dialog based apps. But it is highly
extensible. It is not a tool, but an open source framework that can help to build a skinnable
application in C++. See section 5.3.1 reference [5.15] for more information about it.
6.1.2.5 ExSkin
It is an ActiveX control that enables the developers to change the visual appearance of
their project's forms, providing them with the skin (or look & feel) support. The control
contains a Builder component that helps you to create new Skins. The ExSkin ActiveX
component allows the developer to make their program look like any program from MacOS,
BeOS, Unix, and more. The following table (source: section 5.3.1 reference [5.16]) shows the
compatibility of the product in general terms:
Operating System for Deployment
Windows 98, NT 4.0, 2000, ME
Architecture of Product
32Bit
Tool Type
Component
Component Type
ActiveX (OCX)
Development Language
C++, ATL, STL
Built Using
ActiveX Template Library (ATL)
.NET Ready/Tested with .NET RCW
No
General
OCX96 Compatible
Compatible Containers
Microsoft Visual Studio 6.0, 97
Microsoft Visual Basic 6.0
Microsoft Visual C++ 4.0, 5.0, 6.0
Microsoft Visual FoxPro 6.0
Microsoft ActiveX Control Pad
Microsoft Office 97, 2000
Microsoft FrontPage
Microsoft Internet Explorer 5.5
Product Class
User Interface Components
Table 6.1.1: Compatibility features of the product ExSkin
6 APPENDIX
138
6.1.2.6 DirectSkin (Stardock tool)
It is a skinning tool for any program: it allows changing the appearance of any application
and some functions can be even added, like window rollup or always on top. It allows using
the technology of WindowBlinds but in any property program, using any of the available
WindowBlinds (over 1700) skins or providing the own ones to personalize the product with
the company branding. The option to allow the end-users to choose their skins is also
possible.
Programming Languages: all that support COM objects (Delphi, VC, C++, VB, etc)
What can DirectSkin skin: title bar of the application, title bar buttons. Borders of the
window, push buttons, radio buttons and checkboxes,
scrollbar arrows, scrollbar backgrounds, scrollbar
thumb, menu bar, menus, toolbar buttons, toolbar
rebars, tabs, progress bars, status bars, resize bars,
resize grips, listbox, groupbox, MDI applications,
headerbars, dropdown/combo list box (except their
scrollbars). There are plenty of methods available with
DirectSkin that provide all these features.
Figure 6.1.6: DirectSkin Tool
(source: section 5.3.1 reference [5.23])
Create/Get a Skin: there are three possibilities to get a Skin for DirectSkin:

Get it from WinCustomize site: Most of the there presented Skins should work well
with DirectSkin, but they are not automatically free to use. The author should be
contacted and asked to use his/her Skins. If the end-user is allowed to change the
layout, directing them to WinCustomize site is absolutely acceptable.

Create it manually: See a “Skinning Guide” to do it (see section 5.3.1 reference
[5.14])

Find a Skin author: If an own Skin is needed, a designer can also be contacted and
paid for his/her design (rates >$400)
See section 5.3.1 reference [5.23] for more information about this tool.
6.1.2.7 Object Desktop (Stardock tool)
It is a suite of desktop enhancements designed to customize every aspect of the Windows
environment. The following table (Table 6.1.2) shows the components of ObjectDesktop.
6 APPENDIX
139
Component Tool
WindowBlinds
IconPackager
Description
Platforms
It is a program that makes the Windows GUI fully
Windows
skinnable (title bars, scrollbars, push buttons, the Start
98/ME/2000/XP
bar…) There are plenty of Visual styles that can be
(version 4 only for
downloaded from these already mentioned Skinning sites
Windows XP)
It allows changing the icons on PC (individually created
Windows
icons by the user or by applying created icon packages).
98/ME/2000/XP
Price
< $20
<$20
It complements WindowBlinds in that it comes with icon
packages that are of a particular theme. When a theme is
applied all the icons on the system are changed (not just
a few like Plus! 98 does)
Controlcenter
It is the ultimate virtual desktop manager. It allows users
Windows
to manage windows on many desktops while at the same
95/98/NT/2000
<$20
time monitoring while at the same time monitoring their
resources. It can be configured any way the user wants
(flexibility). Because of its object oriented design, several
uniquely configured ControlCenters can be run at the
same time
WindowFX
It allows adding a huge number of special effects to
Windows 2000/XP
<$20
It allows to create skins for Win 98/ME/2000/XP to be
Windows
<$20
applied with WindowBlinds. It will describe all the skins
98/ME/2000/XP
Windows
SkinStudio
(not necessary to know any skin language). It supports
also ObjectBar, WebBlinds, PocketBlinds and Koala
Player skins
ObjectBar
It allows users to create their own custom Start Bars,
Windows
finders, pop-up Menus, program launchers, wharfs,
98/ME/2000/XP
<$20
docks, etc. It is completely customizable: users can
download plenty of themes and bars for it from the theme
library
WinStyles
It extends window theming to support third party
Windows
programs such as Object Desktop. It is the part of Object
98/ME/2000/XP
<$20
Desktop that allows the users to have all the parts of its
work together to build a complete desktop environment
WebBlinds
It is an Internet Explorer extension that makes IE 5 or
Windows
<$20
It makes possible that users build their own desktops.
Windows
<$20
Rather than replacing the Windows shell (Explorer), it
98/ME/2000/XP
later a fully skinnable Web Browser. It uses WindowBlinds
technology (called DirecSkin) to do this. It is integrated
with IE, therefore users do not loose any function of IE;
moreover, it uses less memory than a fully featured stand
alone skinnable browser. The Enhanced Registered
version
gives
the
IE
SmartBlocking*,
Internet
Performance extensions and more
DesktopX
extends Windows giving it new object-oriented abilities
Table 6.1.2: Tools of ObjectDesktop
6 APPENDIX
140
* SmartBlocking: it is a new Internet technology that returns control of the Browser to the
user. Pop-ups are not just blocked, they are placed into the IE status bar allowing the user to
choose whether they want to view it or not. The website is still paid for the pop-up because it
is still loaded, WebBlinds simply keeps it from showing it.
See section 5.3.1 reference [5.8] for more information about these products.
6.1.2.8 WinCustomize (Stardock tool)
It is a set of programs that customize Windows, which are part of the WinCustomize series of
programs. The following table () shows the different components of this tool:
Description
Component Tool
Cursor XP
Platforms
It is a program that allows to design different “looks
Price
Windows 2000/XP
<$20
Windows XP
Free
It allows skinning the Pocket PCs. It integrates
Windows CE 3.x or
Free
directly into the OS by extending the Windows CE
later
and feels” for the Windows mouse
LogonStudio
It allows editing, changing and applying new logon
screens. It comes built with a visual editor to make
it easy to create the own logos, which can then be
uploaded to websites to be used by other users
PocketBlinds
GWE subsystem, so it is small and fast. The Skins
are truly free form.
Table 6.1.3: Tools of WinCustomize
See section 5.3.1 reference [5.8] for more information about these products.
6.1.3
Platform independent: programming language: C++ and Delphi
6.1.3.1 Skinux
Skinux is a development consulting firm that specializes in implementing custom skin user
interfaces.
Their technology separates the XML description of a skin from the C++ program (MVC)
so that designers and developers can work with each other independently, in parallel. All
Skinux SUI (Skin User Interface) are specified in standard XML with XSLT support. See
figure Figure 6.1.7 to view the components of the MVC pattern.
6 APPENDIX
141
Figure 6.1.7: MVC in tool Skinux
All the following information has been taken from the web site of Skinux (section 5.3.1,
references [5.10] and [5.11]). For more information these references offer much more about
the technology.
GUIs in Skinux are extremely compact: very little memory is required to encode them; gut for
low bandwidth environments, such as wireless Internet appliances or consumer
entertainment devices. Their procedural imaging model enables products to be downloaded
very quickly and rendered on the fly.
Skinux GUIs are based on a patent pending imaging technology that combines effects such
as semi-transparency, animation, sub-pixel positioning, anti-aliasing, and layering to achieve
3-dimensional, photo realistic, dynamic effects. Their technology enables them to create
visual experiences and functionality that are not possible with the API of traditional graphical
user interface technology, which provides little imaging support.
Skinux offers the imaging technology necessary to deliver a truly cross platform solution for
both Windows and Linux systems. Its technology is interoperable with the Win32 and GTK+
APIs, enabling the business customer (B2B) to add a skin user interface to their existing
software without rewriting all their code.
Skinux is a cross platform skinning solution for Microsoft Windows and Linux systems. It
is not dependent on any particular windowing system or operating system manufacturer.
When using a SUI it is important to consider whether or not it is interoperable with the
display technology of the native operating system environment. Skinux excels at it because it
6 APPENDIX
142
does not try to replace the entire display architecture. This is particularly beneficial if a new
SUI is to be applied to a legacy SW, because it is not necessary to rewrite all the code to fit
into a new architecture, resulting in significant savings of time and money.
Skinux is extensible: because they use standard XML with XSLT support, their system
can be extended quickly and easily to meet the specific demands of customers (from
common controls, such as buttons, to customized controls designed by the developers, such
as a play list in a media player).
Skinux architecture: consists of the modular and portable Skinux Software Development
Kit (SDK); the Skinux XML Language, which is easy to use and based on standard XML;
and the MMX Optimized Imaging Library, which enables animation effects and procedural
imaging in real time. The architecture of a Skinux program and its relationship to the Skinux
libraries is shown in the diagram below:
Skinux set provides also plug-in for Adobe Photoshop that export artwork created in
Photoshop to the Skinux format.
Applications of the SUI: Entertainment/Media (MP-3 players...), emulators/simulators, control
panels, launchers (SW installers), Games, Embedded Devices (embedded Linux consumer
device interfaces.
6.1.3.2 TMS Skin Factory
It allows adding skinning capabilities to the Delphi & C++ Builder applications (formerly
known as Varian Skin Factory). The components and the complete designing process are
fully integrated within the IDE (Integrated Development Environment).
It uses no external window hooks like many other third-party skin components. Everything is
done on component/runtime level. The library has already proven itself to be solid and
reliable. It is applicable for the following Programming Languages: Delphi 4,5,6,7 & C++
Builder 4, 5.
See section 5.3.1 reference [5.21] for more information about these tools.
6 APPENDIX
6.1.4
143
Platform independent: programming language: JAVA
6.1.4.1 Action Servlet
It is an open source web application framework. It enhances MVC programming model,
which means that it provides support to create skinnable, multilingual or device
dependent web applications.
Figure 6.1.8: MVC pattern in tool ActionServlet
Important features from source (see section 5.3.1 reference [5.12]) are:

Action-driven: allows easy mapping of user actions (HTTP requests) to methods of
objects

Component-based: any type of components (JavaBeans, Corba objects, EJBs etc)
can be used to build applications

Configurable: by a simple XML file which allows to define action mapping,
parameter passing, automatic type conversions, linking components etc

It tries to minimize the dependence on the framework. ActionServlets
components can be classes of any type and can be used directly (without wrappers)
and therefore, components can be reusable.
See section 5.3.1 reference [5.12] for more information about this framework.
6 APPENDIX
144
6.1.4.2 SkinLF (Skinapplet, Skinit)
It allows skinning any Java application; it provides a total customization framework for swing.
When it is downloaded, the developer becomes not only the look and feel part but also plenty
of utility classes that help him/her in enabling skins in his/her applications. It has plenty of
classes that make it possible to skin any application. There is plenty of documentation for
each of the implemented classes in java. Some of them are, for example: LinuxLookandFeel,
SkinApplet, SkinWindow, SkinLookandFeel...
Skinning an applet is also possible with SkinL&F: “Skinit” has shipped with “SkinL&F” since
version 0.3 and has enabled easy skinning of applications.
/themepack
How does “Skinit” work? Using Skinit, it is possible to load skins
/gtk
gtkrc
from theme packs, GTK themes or KDE themes. Skinit needs
file01.png
the path to the theme and the path to the main class of the
application to be "skinned" (Details of Skin LF's Skinit utility are
...
/icons
Computer.gif
documented in the docs/ subdirectory of the Skin LF
...
/kde
installation).
kde.themerc
file01.png
Figure 6.1.9: Folder hierarchy in themepack.zip
...
skinlf-themepack.xml
Source of the figure 6.2.4 and the following information about SkinLF is in section 5.3.1
reference [5.4].
SkinLF is useless for skinning an applet. Therefore SkinApplet has been created. Its goal is
to offer a simple way to set up the themepack of an applet using the themepack applet tag.
SkinApplet extends JApplet and adds the required method to load a themepack. See Figure
6.1.9 to see the hierarchy of the themepack.
It is able to read GTK (The Gimp ToolKit) and KDE (The K Desktop Environment) Skins to
enhance the application GUI controls such as Buttons, Checks, Radios, Scrollbars, Progress
Bar, Lists, Tables, Internal Frames, Colors, Background Textures, Regular Windows.
It allows developers to bundle a GTK and a KDE theme into one single archive for easy
delivery: a themepack. A themepack is a ZIP file with a specific format: it contains the GTK
theme, the KDE theme and a descriptor written in XML. The purpose of theme packs is to
save the developer the time of searching for proper GTK+KDE theme pairs. Several
themepacks are available at http://www.javootoo.com/ under the SkinLF topic.
6 APPENDIX
145
It has been tested with: Sun Microsystem JDK 1.2.2 (Windows, Solaris, Linux) and Sun
Microsystems JDK 1.3 (windows)
6.1.4.3 Pajes
All the following information has been taken from the web site of PAJES (see section 5.3.1
reference [5.5] for more information about this framework)
Servlet presentation framework that uses pure HTML templates and MVC to allow
skinning of applications and easy creation of sophisticated browser-based user interfaces for
JEE (Java Enterprise Edition) and other servlet-based applications.
100% Java Tool; Pajes separates presentation content from presentation logic and
provides an object-oriented programmatic interface for the manipulation of visual content.
Standards based, Open Source Servlet Presentation Framework for generating HTML
without having to embed HTML tags within the Java Code, and without having to embed any
Java or other non-HTML instructions with the HTML documents. The visual content of a
paje is maintained in absolutely standard HTML pages - no embedded script components
or specialised tags. These HTML page "templates" can be maintained using whatever tools
you or your designers currently employ.
The functional content of a paje is maintained separately. Links between the functional
Java classes and the HTML templates are made via the standard HTML "id" attributes in
the template. Pajes provides "factories" to deliver instances of paje classes built from the
templates as needed, responding to updates to templates (without restart or recompile).
The following picture (Figure 6.1.10, source section 5.3.1 reference [5.5]) shows how the
components of the MVC design pattern are distributed in PAJES:
Controller
View
Model
Result
Figure 6.1.10: Tool PAJES, separation of content and presentation management
6 APPENDIX
146
It allows coding the HTML page with any HTML Editor. The HTML Page is made available
to the java Servlet as an object, where any element within the page can be easily referenced
or changed. Differentiation between HTML design and Java code will be here also done.
The user interface is hold in an external html file, not in code. These files are dynamically
loaded as needed. It allows multiple simultaneously active skins and dynamic alteration of
skins (no recompile, no regeneration, no restart of the web or application server).
A Paje application is abstracted into standard HTML/JavaScript files, which are read,
templated and used as required. Multiple sets of templates can be used by the same server,
allowing a single Pajes instance to provide completely different GUI experiences to different
users simultaneously from the same application. This process is dynamic. If you alter these
HTML Skins Pajes detects it and loads the revised skin and presents it the next time that
paje is to be viewed.
The user interface can “slip its skin” and look completely different, simply by adding varying
HTML templates. Importantly Pajes allows multiple simultaneously active skins and
dynamic alteration of skins - no recompile, no regeneration, and no restart of the web
or application server.
Maybe more importantly, multiple Skins can be active at any time. The same application
or website can be made to look and behave differently for different users or at different
times. The uses for this are many from tailoring look and feel for multiple clients from a
single implementation to simultaneously serving international users with differing local
languages.
The variations in the skins can be anything that a static page can contain, including
variations to colors, fonts, layout, logos, images, language, javascript/vbscript and elements
of DHTML (Dynamic HTML).
6.1.5
Platform independent: programming language: Visual Basic
6.1.5.1 vbAccelerator NeoCaption Component
It is a component that allows skinning the entire non-client area (titlebar, border, menu,
control box and buttons) of a VisualBasic project adding it to a project.
The information that is here given has been taken from the website of this component (see
section 5.3.1 reference [5.18]).
6 APPENDIX
147
This code sample provides a DLL that can be used right away to radically modify the nonclient area of a form, similar to the sort of customization provided by NeoPlanet and
WindowBlinds. And, since the full source code is available, there is also the chance to build
customized client area derivatives.
The DLL supplied with the download exposes two classes for public use:

CNeoCaption: is a reference implementation of the Non-Client area modifier,
including the drawing code and menuing. It implements the INCAreaModifier interface
which must be supported in order to take advantage of the cNCCalcSize class

CNCCalcSize: is the basic framework for building radically customized non-client
areas

cNeoCaption Interface: This should prove to be quite simple to use. There is one
property to initialize the custom caption drawing and a number of others to control
colors and fonts: ActiveCaptionColor, InActiveCaptionColor, ActiveMenuColor,
ActiveMenuColorOver, etc.
The sample provided in the demonstration download show how to use the NeoCaption
component to swap different skins at runtime and even how to remove a skin from a form.
These samples could be improved by putting the caption information into an XML file using
the XML Property Bag component and loading it from there.
cNCCalcSize Object: To gain lower level control over non-client area processing, you can
implement the INCAreaModifier interface and attach directly to the cNCCalcSize object.
Implementing the INCAreaModifier interface involves doing the following:
o
Returning Specific Values
o
Performing NonClient Painting
o
Assigning Window Areas to their non-client function
o
Non-Client MouseDown and MouseUp processing
o
Menu Processing
Implementing these functions from scratch is quite a lot of effort. If someone wants to do it,
the best place to start is to examine how the cNeoCaption class works
6 APPENDIX
6.1.6
148
Platform independent: application dependent tools
6.1.6.1 SAP Editor
This is an editor, created by SAP, which is able to skin any web portal that has been created
with it. The well-known company SAP uses it, precisely to achieve the goal of branding of its
applications and offer its customers the possibility of seeing their own logos and colors in the
software they buy. It is therefore an absolute clear example of “Provider” (B2B) area of
application. Since 1998, SAP began a concerted effort to maintain a consistent branding
language for its software products regardless of the OS on which the software is running. So
far as technology allows, the Java and Windows GUIs of SAP's applications are identical.
It offers customers design flexibility to adapt the look and feel of the portal to reflect their own
corporate branding. Modifying the portal's visual design is easy with the SAP Theme Editor, a
Web-based tool that supports customers in the redesign process.
The Theme Editor even makes comprehensive design changes possible without expertise in
Web programming or scripting languages. It offers a certain amount of design flexibility that
is achieved by:

Placing all design information in cascading style sheets (CSS) instead of writing it
directly into the code.

Using only central style sheets in all HTMLB controls and in the portal outer frame.

Shipping predefined design variants (theme templates) of the portal from which
customers can choose.
Figure 6.1.11: Example of mySAP Portal with logo of SAP
6 APPENDIX
149
The Theme Editor allows a designer or administrator to copy and then modify predefined
theme templates to create a new design. The term "design" is used here to refer to the colors
and imagery of a Web application. With the Theme Editor, an authorized user can change
the look-and-feel of an application without having to be an HTML expert.
After saving your theme, users can then select the newly created theme with the portal
personalize function. If myTheme is chosen, the new theme is activated and the company
logo will be seen on each portal screen (see Figure 6.1.11 and Figure 6.1.12 to view how
different logos can be chosen with the use of this Editor).
Figure 6.1.12: Example of mySAP Portal with custom logo
Customer branding with the Theme Editor works for controls that use central style sheets. If
an attribute is defined directly in the HTML code or if a style sheet is used that is not known
by the Theme Editor, it cannot be changed with this tool
The look of most visible HTMLB controls can be adapted with the Theme Editor. Their
attributes can be found in the SAP HTMLB Guidelines on the SAP Design Guild Website.
Note that this document refers to the mySAP Enterprise Portal 5.0. Note also that the
browser platform determines which attributes can be edited or not. In general, the branding
options for Netscape 4.7 are more restricted than those for other Web browsers.
The Theme Editor as a tool for adapting the portal design runs in the mySAP Enterprise
Portal, but it can also be used outside the portal. As of mySAP Enterprise Portal EP 5.0
6 APPENDIX
150
Support Package 5, this stand-alone version is shipped as part of the Portal Development
Kit. Currently, customization functionality is provided for:
o
SAP Portal Style Editor for partners and external design companies
o
Version 3.0 of the SAP Business Intelligence System
Limitations: The Theme Editor exclusively changes values in style sheets and replaces
image files. This means that only attributes and images which are controlled by style sheets
can be changed, such as colors, fonts, spacing, background images, etc. As no HTML code
is changed, layout changes (for example, changing the position of the detailed navigation)
are not possible with the Theme Editor.
All the previous information and figures have been taken from the web site of this editor,
within the site of SAP (see section 5.3.1, reference [5.22]).

Skinning Techniques in Web Applications

Transcription

Similar documents

il\sNt*,U HE

Brachetto d`Acqui DOCG

Siemens TransformHUV Mexico

Leisure activities and relaxation

Batch Production of Driving Distances and Times Using SAS® and

Succeeding in Mobile Advertising

MIDI-PYRENÉES

Crain`s Leadership Academy 2015

Giving yourself all the chances to succeed... in college !

Xpressions Snap Replacement Graphics