Deliverable (public)

Transcription

Project Number
IST-1999-10375
Project Title
INTELLECT
Document Type
Deliverable
Document Title
Pilot Integration Documentation and Handbook
Document Number
D13
Due Date
01/02/2002
Delivery Date
01/03/2002
Document Status
FINAL
Workpackage(s)
WP04
Security
Public
File Name
INT-D13FINAL.doc
Short
Description
Keywords
This deliverable is a description about the pilot phase within the projects, which is
divided into three different user trials. It shows the work of the pilots, the problems which
occurred, and provide a handbook for the user and technical understanding.
Blauwerk, HiTEC, Interset, Prototype, Pilot, Trial, Implementation, Development Platform
Partners owning
OPTINET
Partners contributed
Optinet, BIBA, Blauwerk, HiTEC, Interset
Made available to
Jorge Gasós (CEC)
INTELLECT
IST-1999-10375
Letter of Content
1
Executive Summary.......................................................................................................................... 4
2
Introduction ....................................................................................................................................... 5
3
Pilot One: Blauwerk .......................................................................................................................... 7
4
5
6
7
3.1
Requirements of Blauwerk ........................................................................................................ 7
3.2
Surface structure ....................................................................................................................... 8
3.3
Requirements to the developing partners ................................................................................. 9
3.3.1.1
Blauwerk ..................................................................................................................... 9
3.3.1.2
Atlantide ...................................................................................................................... 9
3.3.1.3
BIBA .......................................................................................................................... 10
3.3.1.4
Optinet ...................................................................................................................... 10
3.4
Integration of the modules....................................................................................................... 10
3.5
Feedback of the first prototype version of Blauwerk ............................................................... 12
3.6
Starting of the pilot .................................................................................................................. 14
3.7
Discussion of the missing features with Blauwerk .................................................................. 15
3.8
Set-up of an improved pilot ..................................................................................................... 15
3.9
Conclusion............................................................................................................................... 18
Pilot Two: HiTEC ............................................................................................................................ 20
4.1
Requirements .......................................................................................................................... 20
4.2
Surface structure ..................................................................................................................... 21
4.3
Feedback of the prototype of HiTEC ....................................................................................... 22
4.4
4.5
Discussion of the missing features with HiTEC....................................................................... 23
4.6
Conclusion............................................................................................................................... 24
Pilot Three: Interset ........................................................................................................................ 25
5.1
Requirements .......................................................................................................................... 25
5.2
Surface structure ..................................................................................................................... 27
5.3
5.4
Conclusion............................................................................................................................... 29
INTELLECT prototype .................................................................................................................... 30
6.1
First prototype.......................................................................................................................... 30
6.2
Current surface structure......................................................................................................... 31
6.3
Second prototype .................................................................................................................... 33
6.4
Common open issues.............................................................................................................. 36
6.5
Conclusion............................................................................................................................... 37
Handbook ....................................................................................................................................... 38
7.1
Architecture ............................................................................................................................. 38
7.2
Installation Guide of the client’s software................................................................................ 40
7.3
Product Data Model................................................................................................................. 41
INT-D13FINAL
© The INTELLECT consortium – 2002
Page 2 of 50
INTELLECT
7.4
IST-1999-10375
User Handling.......................................................................................................................... 45
7.4.1
Managing the VR representation of products .................................................................. 45
7.4.2
VR Graphical User Interface for the customer ................................................................. 47
8
Conclusion ...................................................................................................................................... 48
9
Annex.............................................................................................................................................. 49
9.1
Pictures from the whiteboard from Blauwerk’s prototype........................................................ 49
INT-D13FINAL
Page 3 of 50
INTELLECT
IST-1999-10375
1 Executive Summary
This deliverable is a description about the pilot phase within the projects, which is divided into three
different user trials. It shows the work of the pilots, the problems which occurred, and provide a
handbook for the user and technical understanding.
The prototypes of the project INTELLECT were available since the middle of the year 2001 till the end
of the project at March 2002. But there were not all prototypes at the same time available. The first
one was Blauwerk in Austria, which has been developed and tested. After that first prototype
development, which takes into account new user requirements, the second and third pilot had time
problems, because of missing information about the products and adaptation of the 3D objects.
Therefore we decided to develop as a second part an INTELLECT prototype which includes all
features we want to included. This prototype has been used for the HiTEC pilot from September 2001
till March 2002. After that development the project created a prototype for the Greek company Interset.
That prototype has been established from December 2001 till March 2002. Summarised, all pilots run
in the last decade of the project successfully, but we had several problems to solve before.
This deliverable will describe the different prototypes, the problems, the successful story, and the
further user requirements which have been included. Additionally, the technical issues are described.
Furthermore, this deliverable will be a guideline and handbook for the used prototypes to give a better
impression about the functionality and handling.
INT-D13FINAL
Page 4 of 50
INTELLECT
IST-1999-10375
2 Introduction
The fourth phase of the INTELLECT project brings together the necessary hardware infrastructure
including the network connectivity with the developed and selected software system. The information
repository has be populated during this task. Simultaneously a scenario environment has been defined
to be used for a plentiful testing of the complete system. This testing wants to cover technological and
logical functioning of the system.
This task has a crucial importance because the pilot has to be matched against its user-friendliness,
integration and convergence across information processing, communication and media. The
involvement of the end users has been very close. The satisfaction of the end user's needs and the
completion of the database needed at the end users sites is a milestone of the pilot phase and the
overall project.
As a result of the implementation work package the complete set of laboratory tested modules have to
be available. As far as they are not already installed at the pilot sites, this has been done as part of
this work package. The integration of the overall system has reached in a step-by-step procedure
interconnecting the individual subsystems. This includes the integration of the system at the pilot sites
with existing database management systems as well as the population of the information repository
with a sufficient set of product data.
Since the users are consortium members, or members of the user group established during the
beginning of the project, they are already familiar with the concept of the INTELLECT system to be
implemented. Nevertheless, one of the objectives of this work package is to give them instructions for
the usage of the configuration module and to record this in a usual operating instructions booklet. This
includes instructions about hardware operation (so far as necessary), software operations and
procedures to be followed to achieve the aimed goal.
The different pilots can be divided into the following different prototypes:
1. Blauwerk: Austrian pilot, which includes a scooter supplier and seller. The user requirements
are to create high quality pages which includes configuration features of the products and
multi-media entertainment to create a brand. Neither help-desk features are needed from the
user nor direct voice support. A direct order has to manage by the order processing module
and should create an e-mail message. The connection to the Internet is only by ISDN dial-up
connectivity available.
2. HiTEC: Austrian pilot, which includes a bicycle supplier and seller. The user requirements are
to create high quality pages which includes e-shop features and configure possibilities. An
help-desk is needed, because of the very different components which are available for the
bicycles. A direct order has to manage by the order processing module and should create an
e-mail message. The connection to the Internet is only by ISDN dial-up connectivity available.
3. Interset: Greek pilot, which includes a computer supplier and seller. The user requirements
are to create an e-shop system which makes it possible to order directly. Also an detailed
overview about the ordered components should be integrated. An adaptation of the existing
SAP system would be useful by the order system. Help-desk features regarding direct support
via voice, video, and mirroring are welcome too. The connection to the Internet is only by
modem dial-up connectivity available, but the server can be hosted by another provider.
4. INTELLECT: Common prototype, which includes all modules which have been developed.
The surface should be look like the Internet pages of INTELLECT to get a common view. This
prototype has been used as a test scenario on the development platform and also as
prototype if there will be any problems at the user trials with the respective prototypes
available.
The following figures present the overview about the work package 4 work plan in detail.
INT-D13FINAL
Page 5 of 50
INTELLECT
IST-1999-10375
Figure 1: Project overview about work package 4, part 1
Figure 2: Project overview about work package 4, part 2
INT-D13FINAL
Page 6 of 50
INTELLECT
IST-1999-10375
3 Pilot One: Blauwerk
nd
After the 2 review the prototype was not stable enough for using in a user trial. To get a stable
prototype we installed a running Linux system at the BIBA’s site and configured all software tools on
this single server workstation (also the Oracle database). Next issues were the integration of SSL,
NetMeeting as third party tool for voice, video and data sharing, and a perfect adaptation of the frontend/back-end functions.
The configurator module from BIBA is working and needed data for a further pilot integration in the first
phase. Therefore Blauwerk provided information to BIBA regarding. A better co-ordination between
the names/types of the configurator and the user requirements were necessary for the administration
and configuration for users/customers.
nd
The 3D view status was presented at the 2 review and had to be extended by animation and avatar
functionality. Unfortunately, Atlantide was not able to handle this, because they are not experience in
the creation of 3D objectives and had problems to fulfil the objectives regarding animation and avatar
functionality. Therefore, Atlantide had to find a way, either how to create the VRML files, or find an
alternative product presentation.
The order processing was working and had to be adapted to the user requirements. That included the
interaction with the E-Shop module and the user databases. The help-desk system is written for
Tomcat 4.X. Therefore we had problems to integrate this functionality into the prototype of Blauwerk.
But on the other hand, Blauwerk did not need this feature, because of the nature of their customers.
Therefore, the NetMeeting third party tool has been implemented on the INTELLECT pages at
http://www.ist-intellect.com and after that in the first pilot of Blauwerk.
3.1 Requirements of Blauwerk
Additionally to the user requirements we found out at the start of the project in WP1 there were some
more user requirements from the end users within the project INTELLECT as they became an idea
what the prototypes could be. Regarding the company Blauwerk the following wishes occurred:
1. Visualisation of single products in 2D must be possible
2. Configurations must be visualised
3. 3D is not necessary for Blauwerk, but would be welcome if it looks good.
4. An avatar is necessary, incl. animations, because Blauwerk wants to transfer a “look & feel”
5. QuickTime or RealPlayer videos or video streaming sessions should be integrated
6. Grey background on each web site
7. Navigation buttons (Elevator buttons) will be placed at the bottom of each subpage
8. The buttons must have an „mouse-over“ effect (change to buttons colour)
9. Quark Xpress is not useful for design adaptation for Optinet; it is more sufficient to use Adope
Illustrator to create HTML pages using other prodcuts from Adobe.
10. Configurator button should be on each site; also on the home site
11. Component typs for the city-bike should be available
a. Frames
b. Wheels
c.
Fork
d. etc.
12. Structure
a. Configuration of your personal bike should be available on each site
b. Home (Starting Page) the logo should be animated; this must be done by Blauwerk
(GIF animation or flash)
INT-D13FINAL
Page 7 of 50
INTELLECT
IST-1999-10375
c.
eShop (order process) – should be merged with the products category (e.g. Willy, City
etc.)
d. Products: world-of-experience should be shown
e. Where to ride
1. Industry
2. City Shopping
3. Freebyke
4. Leisure time / sports
ii. Who we are
iii. News
iv. Configure your personal sidewalker
v. Languages (German and English)
vi. Sign-up
vii. Contact
f.
Differentiation between a customer and a retailer, B2B login
g. Integration of video streams (should be available from Blauwerk): different qualities for
different access bandwidths
This user requirements had to adapted to the current available prototype of INTELLECT and lead to
an open process of development during the whole project.
3.2 Surface structure
Regarding the XML/XSL structure of the prototype there are the following wishes from Blauwerk:
1. Products: Overview over the scooter types (9 pieces); for the pilot only one or two types
should be configurable, but all types will be shown in an overview (in 2D)
a. After that overview a site with details will be shown with a big picture of the chosen
scooter
b. Buttons will be at the bottom of each page
2. Where to ride: Division in four areas
a. Downhill
i. Pictures- and video clippings
ii. History
iii. Animation
b. City Shopping
ii. History
iii. Animation
c.
Freebyke
ii. History
iii. Animation
d. Camper
INT-D13FINAL
Page 8 of 50
INTELLECT
IST-1999-10375
ii. History
iii. Animation
3. Who we are
a. Blauwerk’s story
b. Profile
4. News
a. Archive
b. Newsletter
c.
Press release
5. Login / Sign-up
a. Normal customer
b. Retailer
6. Contact
a. E-mail
b. Site Plan
c.
Retailer overview
d. Telephone
e. Opening hours
3.3 Requirements to the developing partners
The user requirements lead to the following requirements to the developing partners of INTELLECT
and Blauwerk itselfs regarding to fulfil the work in work package WP04.
3.3.1.1 Blauwerk
-
Adope Illustrator data is necessary at least to set-up HTML pages and adapt this pages to
XML/XSL
-
Approx. 11 page layouts will be created, mainly focused on the products (catalogue)
-
Product information:
i. pictures in 2D
ii. Names
iii. Short/long description
iv. Order Number (internal catalogue number)
v. Price, excluding of value added tax
3.3.1.2 Atlantide
nd
-
Much better visualisation of the components as we saw at the 2
-
If one component will be replaced, the price has to be adapted, too
-
Configurable components should be visualised, too
-
Avatars should be available either in the 3D view or in the animation
-
Improvement of the administration/configuration
-
Improvement of the GUI-design is needed
INT-D13FINAL
review meeting in Brussels
Page 9 of 50
INTELLECT
-
IST-1999-10375
The currently selected component should be displayed beside the whole product
3.3.1.3 BIBA
-
Storage of the configuration every time
-
Better mapping of the product categories with the module
-
No absolute database addressing, static references in code
(arrangement with Anecon)
-
Playing with the products must be possible (without using the
basket); one possibility is to configure own products with an
anonymous login
-
Screenshots from the configurator, 3D module, and eShop for
the layout person to get a better impression
-
Software installation on the user site is necessary to be able
to use the 3D applet/view
-
No static paths, but a use of a configuration file as Anecon
implemented
-
Basket: Infos to the order processing
3.3.1.4 Optinet
i. Product group
ii. Product number
iii. Product name
-
Standard configuration or new configuration
3.4 Integration of the modules
At the user integration meeting in Vienna at July 2001 the first pilot has been started. First of all the
different status reports from each module were presented and discussed with the end-users. At this
meeting also the detailed project workplan was discussed with the available partners. Here you can
read the results of the report from July 2001.
The e-shop needs a further work on the back-end system regarding to reach a more stable status.
But, the adaptation of the back-end functionality to the front-end site is ready. Additionally an
adaptation of the front-end design to a common INTELLECT design has been done. The XML surface
divides all visible areas of the surface into objects. That makes possible a very flexible work. Bug-fixes
regarding further the adaptation failures are necessary. Also a SSL access via Tomcat and Cocoon
has to be integrated for a secure communication between the customer and the e-shop site. Also
further implementing of more back-end functionality regarding the user requirements is wanted. At the
first step the HTML sites had to created, because the end-user Blauwerk was not able to create this
pages on their own without help. Therefore a complete concept was developed from Optinet for the
end-user’s web-sites. Afterwards the adaptation of the created HTML pages to XML/XSP had to be
done.
The virtual reality module developed no progress since the last integration meeting in May. That
means in July there are no development available regarding the avatar or the animation of bicycles or
scooters. Also, not any adaptation has been done of the other modules to the existing user
requirements. Atlantide promised to establish the development of the avatar and the animation as
soon as possible. Additionally the 3D data will provide by Atlantide if other ways are not possible (e.g.
to get this data from the producer or the user). The implementation of the Java 3D applet into the web
site and 2D view should be possible too. But this features are still missing till today.
The configurator consists of the new product data in the database. Therefore the city roller is
complete, but another scooter is still missing. No problems occurred during the implementation. But
more information were not available. The information inside the database can be used for the e-shop
INT-D13FINAL
Page 10 of 50
INTELLECT
IST-1999-10375
module too. Furthermore a configuration file is necessary for all static data (e.g. database connection,
type name, etc.).
The help-desk system adapted the third party tool NetMeeting for the INTELLECT pages under
http://www.ist-intellect.com. We used one official IP address from BIBA to test the implementation
carefully. In July open questions were the direct agent support and the adaptation of the mirroring
mechanism. No further progress regarding the mirroring was available, because of no progress in
Tomcat 4.x and Jboss integration.
The order processing has been extended of the basis functionality. An e-mail can now include a
detailed list of components for every ordered product and further content of the order. Arbitrary
configureable sequence status is also available. Branch within the workflow with alternative sequence
status is possible. Also error handling and an auto-Trigger event (for each status can be defined as an
event) have been foreseen. But, the working together with the database of Itchy (the development
platform) seems to be a bit buggy. Also there is missing content (text) from Blauwerk regarding the email messages.
The web-site has been extended with new articles, information, and a help-desk function. This
means, the help-desk third party tool NetMeeting is available on the INTELLECT page under the
question mark of each site. This functionality is only for test possibilities available, before we integrate
it into the INTELLECT system. Also the prototype is available by a direct link on the site, which will
show the INTELLECT system with its own design.
Figure 3: Public site of INTELLECT with updated information
The problems with NetMeeting regarding NAT, firewalling, and dynamical port numbers are mentioned
on the help-desk web-site (see Figure 4). Also the tool NetMeeting is available there. The web-sites of
the INTELLECT project has been also published on a CD-ROM at September. Here, people who are
interested in can get information of the project (in a similar way as they can get information by the
web-sites). Additional information will be a photo gallery of each partner meetings and some small
videos. Each partner gets one or more CD-ROM(s) for marketing activities continuously.
INT-D13FINAL
Page 11 of 50
INTELLECT
IST-1999-10375
Figure 4: Help-desk site with integrated NetMeeting
The outcome of that first pilot phase was that further adaptation of the modules is necessary to get a
stable prototype as demonstration platform. The set-up of the next pilots will be the same work as at
Blauwerk. The partners have to collect data and information after the same example.
3.5 Feedback of the first prototype version of Blauwerk
After the development of the prototype for Blauwerk the first feedback of them were necessary to
improve our development and integration further. The Figure 5 and Figure 6 shows the results of the
first realisation. Figure 5 shows the start page which is based on a “shop-xml” file as you can see.
From here you can go inside the different pages, which have been defined at the first workshop at
Blauwerk.
INT-D13FINAL
Page 12 of 50
INTELLECT
IST-1999-10375
Figure 5: Home site from Blauwerk
Figure 6: Where to ride site from Blauwerk
INT-D13FINAL
Page 13 of 50
INTELLECT
IST-1999-10375
The remarks from Blauwerk were (more or less) available regarding design and feeling. This end-user
is very strong about things like subjective feeling and handling of its own products. As you can see the
current pages under http://www.blauwerk.at there is a big progress available to the new designed
pages. The following notes came from Blauwerk regarding their new surface:
-
Arial should be used as font type
-
The same font type size for all pages
-
New configure logo should be send as new picture from Blauwerk
-
“Sign up” will be “login” with two submenu “login” and “sign-up”
-
New navigation button image should be send from Blauwerk
-
Every button has the same size
-
Home button with Blauwerk logo will be added to every site as the first button of the navigation
list
-
German version should be developed in the future
-
“AGB” submenu should be added to “shop now”
-
“Where to ride” should be used instead of “See it,feel it,do it” in every site
-
The name of the active site in the navigation list should be showed in red
-
The button of the active site in the navigation list should flickering like a heart, when this is too
difficult, then use the button with grey middle point
-
Large photos should be send from Blauwerk
-
The large photos should be showed in a new window with a size over 250x150
-
High resolution and low resolution of the video should be showed in a new window with the
size over 200x150
-
“See yourself ride” site will established similar as the configuration site
-
New design for the site „community“, “basket“, “order“, “check out“, “thanks for shopping“, and
„no shopping“ should be sent from Blauwerk
-
Sub-menu “production info” should be added to “who we are”, and the design should be sent
from Blauwerk
-
In the site “cityLTD”, the link with the site ”citySFD” should be added by the cityLTD image
-
Each text for the site “contact”, ”news”, and “who we are” should be sent from Blauwerk
3.6 Starting of the pilot
After the user integration meeting the pilot started at the end of July till now. Only the client site has to
be prepared for the 3D view, because we handle all other things separately on the server site
(development server Itchy at the BIBA institute). The installation on the client site is not very useful
and a little bit complicate. Therefore, Optinet supported the user by the installation process
continuously.
During the installation of the client software on a Microsoft Windows ME system occurred the following
problems:
o
Problems with the Java 3D extension
o
No OpenGL 1.1 support at Microsoft Windows ME (Windows NT with service pack 3
includes OpenGL 1.1)
o
Java 3D is not able to install on Windows ME, maybe because of missing rights on the
Java Environment
We had to do some more tests for Windows ME, but it was necessary that Blauwerk switch to
Windows 2000, because of the existing problems with Windows ME. In July we had still no 3D data
INT-D13FINAL
Page 14 of 50
INTELLECT
IST-1999-10375
which fits to the database data. Therefore, it was not able to start the pilot with real data! This is also
still the problem at the end of the project.
3.7 Discussion of the missing features with Blauwerk
Regarding the different modules Blauwerk discussed several improvements with the developers
directly. Especially, the order processing and the virtual reality are from special interest for Blauwerk
and had to be discussed:
1. Order processing
a. The whole order takes one way from customer to the supplier; the order is orderbased not product-based
b. Splitting from configured products and standard products should be possible, because
the standard products are available on special sites worldwide and the configured
products should be handled in Vienna directly
c.
E-mail orders can not be handled if the order increase: this must be automated, e.g.
with a ERP system like SAP
2. Virtual Reality
a. Animation of the avatar is necessary for Blauwerk
b. A few parameters should be available
i. Size of the avatar
ii. Male and female avatar
c.
3D visualisation is not important for Blauwerk; therefore a 2D visualisation must be
able to use
d. Is it possible to integrate the Java applet into the web page?
i. 3D data are not available by Blauwerk and probably also not by the other user
partners.
ii. Therefore, Atlantide has to provide “dummy” 3D data
iii. Copyrights will not be a problem, because we can use this data only for the
prototype (well enough for marketing or advertisement from the provider
point-of-view)
Another possibility was discussed with Atlantide regarding the extract of 3D data from 2D
photographs. Some tools exists and have been tested. But there was no enough user support from
Atlantide to get this data in a well enough quality from 2D data.
3.8 Set-up of an improved pilot
After the missing parts were integrated (but something is still missing), the next prototype for Blauwerk
was established. Find here the new style and surface of the improved prototype. Also the surface was
new structured and several templates were foreseen to get better possibilities to adapt the next pilots
in less time than the first one. The technical description you can find in the handbook in this
deliverable.
INT-D13FINAL
Page 15 of 50
INTELLECT
IST-1999-10375
Figure 7: Start page of Blauwerk
Figure 8: Login mask for the customers
INT-D13FINAL
Page 16 of 50
INTELLECT
IST-1999-10375
Figure 9: Template for getting the user profile
Figure 10: Product which can configured and add to the basket
INT-D13FINAL
Page 17 of 50
INTELLECT
IST-1999-10375
Figure 11: Client VR configuration applet
Configuration of the product is accomplished as follows (Figure 11). The user can select the
component he wants to modify in the components list or in the viewing area, if he is in the interaction
mode, and if the 3D model is available. The customer indicates then, that he wants to replace this
component, thereby opening the component exchange dialog (see Figure 12).
Figure 12: Component exchange dialog
The component exchange dialog displays the list of possible components that can replace the
selected one. This component list is generated by the Configurator from the product database and
represents the subset of available components that will fit into the product physically and mechanically
and at the same time meet all the “soft” criteria specified for this product, or manually specified by the
user. Selecting a component in this list shows a 3D view of the component (if available) and its
technical description (see Figure 12).
3.9 Conclusion
The meetings in Vienna were necessary and useful to go a big step further to complete the first
prototypes and to start the prototypes. Nevertheless after the first sessions the developing partners
got their work to establish the prototype without bugs and limits. Furthermore, the experience from the
first pilot was very helpful for establishing the next pilots at HiTEC, Austria and Interset, Greece. The
project has saved time for this next project phases. Get at the next two figures some impressions of
the meetings in Vienna.
INT-D13FINAL
Page 18 of 50
INTELLECT
IST-1999-10375
Figure 13: Sitting together at Blauwerk’s office for the client preparation
Figure 14: Scooter from Blauwerk
INT-D13FINAL
Page 19 of 50
INTELLECT
IST-1999-10375
4 Pilot Two: HiTEC
After the first pilot has been started the next pilot in Austria has been established. Because of the
missing 3D objects, and the new developed web pages of the end-users, in the first phase we used
the INTELLECT prototype for the user trials. There was a widely underestimated problem of
getting/generating 3D data for the product components to be configured:
1. The first reason for this was, that 3D models would have had to be based on real
construction data, the details of which the suppliers did not want to make public.
2. Secondly, there were no affordable and easy-to-use tools to generate 3D data from the
component data, which the end-users had available.
3. Thirdly, any substantial outsourcing of rendering tasks to professional suppliers would have
resulted in massive overspending of the project budget.
4. The attempts to collect appropriate 3D data from suppliers required much of the resources
initially planned for testing. Numerous contacts to the top-level managers of international
companies like shimano or manitou had to be established and many discussions were held
but yielded no results.
5. There were also attempts or to generate 3D data within the consortium. They were based on
existing plans and additional 2d constructions made specially for the project. These data,
however, also turned out to be no sufficient basis to create the necessary 3D models.
In that cases the most of the Testing had been done on a generic level with the INTELLECT prototype
shop with generic 3D data objects. The products of the end-users were de-composed for the
configurator and all the rules for combinations have been defined. The end-users like HiTEC redesigned and re-launched their web-sites to provide the foundations for the shop-to-be.
4.1 Requirements
The requirements from HiTEC are very similar to the requirements of Blauwerk. They want to improve
the 3D visualisation like Blauwerk, too. But against Blauwerk, they know how to create HTML pages
and use new web technologies like Flash. Because of a complete re-design of their web-pages, which
has been done by HiTEC on their own advise, the project INTELLECT had to wait on this results. That
means we had additional delays for this pilot in Austria.
The following requirements from the project to HiTEC are:
-
HTML pages for the pilot are necessary
-
Information about the products is necessary for the database
-
Information about the rule structure for the configurator
-
2D photography from the products for the 3D modelling
-
Data for workflow and email text is needed for order processing
And there were also special user requirements from HiTEC to the development partners:
-
Better visualisation of the 3D view, because of they high-end bicycles
-
Sufficient handling of the configurator components
-
Fast access to the Java3D window
-
High-end pictures of the bicycle’s components
-
Help-desk system for a direct support during the choice/configuration of the product
-
Basket functionality and overview about the chosen products
The big advantages of the end-user HiTEC was that they develop their own pages without direct help
of the developer partners. Therefore all other partners had time to develop the back-end in a more
perfect way.
INT-D13FINAL
Page 20 of 50
INTELLECT
IST-1999-10375
As you can see in this surface structure there has been foreseen INTELLECT parts like the
configurator, basket, and user login. All pages are available as Flash and HTML.
Figure 15: Start page of the HiTEC web pages
Figure 16: Configuration page of HiTEC
INT-D13FINAL
Page 21 of 50
INTELLECT
IST-1999-10375
Figure 17: Product in detail
Figure 18: Contact page for user profiling
4.3 Feedback of the prototype of HiTEC
Because of the self development of the web pages there was no feedback necessary. For the product
data and the integration of INTELLECT features there were an exchange of information continuously.
INT-D13FINAL
Page 22 of 50
INTELLECT
IST-1999-10375
The pilot has been started in September 2001 with the prototype of INTELLECT. Therefore, only a
scooter and different PC components have been used. For the technical description please read the
chapter about the INTELLECT prototype. So, the experience of the pilot was, as here mentioned,
based on a generic level.
The mountain bikes produced by HT Trading consist of parts purchased from renowned suppliers like
Shimano, Marzocchi, Manitou. When the representatives of these producers were contacted for the
first time the first half of the year 2000 with information about the Intellect Project, there were positive
and encouraging reactions. The industry appreciated the potential of promoting high-end equipment
through appealing VR/3D representation. Industry representatives especially stressed the necessity of
a detailed presentation of the product features to justify the higher prices of professional components.
When the first prototype had to be filled with real data, the first problems were encountered. According
to the producers there were component data available, both in 2d and 3d format. Some of the
companies even had rendered product files for simulation purposes. However, the company
representatives were reluctant to give this information to outside parties.
HiTEC contacted suitable producers on numerous occasions:
-
Marzocchi Spa (Bologna/IT) was contacted on the Taipei Cycle Show in April 2002 on
management level. The result was, that the company would reconsider their point of view –
after a few weeks an numerous meetings with the Austrian representative, HiTechs request
was turned down,
-
A formal meeting with Shimano Europe Gmbh. (the European branch of the world market
leader in gear shifting and brake equipment) took place at the “EuroBike” Fair in
Friedrichshafen. Also the European General Distributor participated in this meeting. Again no
decision was taken at this event, but was postponed for further internal consultations. After a
few weeks and two meetings with the head of the marketing department Mr. Zeilberger only a
CD with component images was sent with an apology that this is all what Japan was ready to
distribute.
-
For the negotiation with Answer Products USA (Manitou etc.) HT was in a better position,
being the general representative of the company in Austria. The first request for data, with
which 3d models could be generated, was communicated to Answer at the Taipei fair of 2001.
Through the regular contact with the European Management the headquarters in the States
was pushed even more. Nevertheless the request was rejected. Only after an intervention in a
personal meeting with Glen Miller, Answer’s president an assent could achieved. It took until
11/2001 until one file with the construction data of a 2 two year old fork reached HiTech.
The situation is maybe bets explained by a mail sent to HT by Manitou Inc. during the negotiation
phase, in which the development department explains that “.... any competitor would be able to use
the data for copying our product to the very detail. It even would be able to feed the information to
production machines and get a bootleg product within a few hours”.
4.5 Discussion of the missing features with HiTEC
The lacking co-operation from the suppliers was a major drawback for the overall goals of HT and
endangered the whole strategy of bike configuration via the Internet.
As a consequence HT Trading tried to get 3D data from other sources. First there were attempts to
capture construction data by copying them by a CAD system. HT technicians, though experienced
with system used hours of drawing time without promising results. 2D construction plans could be
generated quite easily, because it was similar to the development work being done for the
components designed by HT personnel. When it came to adding the third dimension to these
drawings, the problems could not be overcome. Firstly an abundance of additional data would have
been necessary to give in. Secondly, additional program components would have been necessary
together with lengthy qualification measures for the employees involved.
rd
All in all, no economic way of generating 3D in-house could be found. So, contacts with some 3 party
suppliers of rendering services were established. But very quickly it became apparent, that
outsourcing the production of 3D models of existing parts would also become a very expensive task.
INT-D13FINAL
Page 23 of 50
INTELLECT
IST-1999-10375
There were bids for creating a detailed 3D model of key parts like gear shifts components at about
3.000 Euro, which would rise the price of a fully equipped VR-mountain bike summed to over 20.000
euro.
As a potential alternative, there were contacts to a company providing 3D scanning services. But also
in this case, the cost was way too high for a economic production of the necessary data (app. 5.000
Euro per hour including personnel, with the potential outcome of 1-2 parts per hour).
Also within the consortium there were attempts to generate the necessary data for the visualisation
module using. Existing blueprints were transferred to CAD systems and tested by development
partners for their usability as source material for rendering.
In anticipation of the configuration capabilities, the web-pages of HiTEC was completely redesigned.
The company’s strategy to offer different variants of the same bike was already apparent in the recent
versions of the site, but different components were only shown in text form.
The new web-pages was designed for highlighting the different variations and to show a picture
(maybe later a 3d model) of every key component. There was the goal to provide a clear structure for
the configuration of different bikes based on standard models, which could be upgraded/stripped down
by the prospective buyers.
This aspect was also considered by the organisation of the bike’s components, which was elaborated
for as a basis for configuration module of the Intellect Shop. It had to enhanced from a simple part list
to a multi-level component structure, where each level consists of – interchangeable – parts, which are
combined to modules being the parts for the next level.
The conception and development of the overall web-pages was done in in co-operation and with
support of the developing partners, but also yielded problems. HT’s long-standing local web designer
had foreseen a different technical background (flash), which was hard to fit into the technical concept if
INTELLECT, which is based on XML. That caused a delay for the establishment of the pilot with the
original pages and is not solved yet, because of the less time till the end of the project.
Because of the incomplete prototype of HiTEC, there are some important features still missing:
-
Adaptation of the HTML pages to XML/XSL pages
-
Integration of the SSL
-
Integration of real VRML data (3D objects)
-
Integration of help-desk functions (NetMeeting and mirroring)
-
Further extension of the database content
Other features like the configurator, user login/profile, and 2D visualisation have been complete
integrated.
4.6 Conclusion
Summarising it might be said, that there was a massive under-estimation of the efforts, which would
be required for getting the basic data for a VR/3D shop in general. The suppliers had understandable
objections against giving away construction details, which could be used for copying the components,
But without their co-operation, a different concept would have to be used. Maybe economic 3D
scanners would have solved the problem. Or, if he 3D representation aspect would have been
foreseen in the construction process, more simple and not so secret-revealing CAD files could have
been used.
The consortium also had to learn, that maybe 3D technology available at the moment is still too
sophisticated and costly to be used in a plain commercial project. There was no way to justify the
additional costs for creating VR promotion material, since it would not necessarily yield so much
additional turnover/profit to break even within a reasonable time frame. 3D technology - when not
already foreseen in the construction process and therefore produced only for marketing reasons –
would almost double product development cost and would therefore considerably reduce the
producer’s margin.
INT-D13FINAL
Page 24 of 50
INTELLECT
IST-1999-10375
5 Pilot Three: Interset
The prototype for the pilot of Interset has been finalised with a delay too. That reason was that also
here the re-launch of the web-pages needed time. Interset developed and designed there web pages
on their own. Therefore no navigation structure, additional features/requirements, or design has to be
developed from the partners of INTELLECT. Under advise of the partners they established their webpages with the additional features of the project.
5.1 Requirements
The user requirements from Interset did not changed since the first definition in WP01 has been
started. Therefore nothing had to new adapted. Additional they don’t need 3D visualisation, because
of their products (it is not necessary to show a motherboard or a graphical board in 3D).
The requirements from the project to Interset were:
-
Information about the web-sites (if possible as HTML) for the pilot
-
Information about the products
-
Information about the rule structure for the configurator
-
2D photography from the products for the 3D modelling
-
Data for workflow is needed for order processing
The technical description of the products is very deep.
The next table shows a Ultra SCSI connectivity, BIOS on card, data transfer rate up to 20Mbps. This
input is available in the database to make a configuration possible.
Why to buy
Boost your CD-recordable or Jaz drive to its best performance
System Environment
Desktop PCs
Key Differentiators
Ultra
BIOS
EZ-SCSI Deluxe Edition
SCSI
on
connectivity
card
Data Transfer Rate
Up to 20MB/sec
External Connectors
50-pin High-Density (SCSI-2 female)
Internal Connectors
50-pin standard (male)
Bus Type
32-bit PCI
System Requirements
INT-D13FINAL
Page 25 of 50
INTELLECT
IST-1999-10375
IBM-compatible
PC-486,
Pentium
or
above
Windows 2000, ME, NT, 95/98, 3.1, or DOS operating systems
PCI
expansion
slot
SCSI peripheral
Package Contents
SCSI
EZ-SCSI
50-pin
internal
Quick
Reference
Registration card
Card
SCSI
cable
(external
installation
cable
not
2930U
software
included)
guide
guide
Warranty
5-year manufacturing and materials warranty
Picture:
Another technical specification of a motherboard are:
®
TM
Supports Intel Pentium III/II CuMine, Katmai and Celeron processors, 2 x DIMM for up to 1GB
PC133/HSDRAM (high speed), UltraDMA/66, 5 x PCI, 1xAGP.
The technical specification is:
®
The ASUS CUV4X-C Mainboard is based on the VIA 694X chipset with ATX form factor for the latest
®
TM
support in Intel Pentium II/III 300~1GHz+ Coppermine and Celeron processors. This fascinating
chipset is equipped with 133MHz Front Side Bus (FSB), and support for PC133 SDRAM and AGP 4X,
Ultra DMA/66, Wake-On LAN and Ring. It is also bundled with ASUS PC Health Monitoring to monitor
and ensure maximum safety for your PC.
Chipset Feature
®
VIA 694X is a high performance chipset which uses 82C686A South Bridge to offer 133MHz memory
bandwidth for supporting wide range of PC133 memory devices.
•
Supports Intel Pentium III/II CuMine, Katmai and Celeron
•
133MHz Front Side Bus
•
5 x PCI, 1 x AGP
•
2 x DIMM for up to 1GB PC133/HSDRAM (high speed)
•
UltraDMA/66
•
PC Health Monitoring
®
INT-D13FINAL
TM
processors
Page 26 of 50
INTELLECT
IST-1999-10375
Picture:
That information shows that 3D is not useable in this pilot and there are many database information
available for all the different components and categories.
The surface structure of the pages of Interset were set-up by Interset! They also adapt their HTML
pages to XML/XSL code. Optinet had to only advise the partner regarding the additional features of
the INTELLECT e-shop system and had to adapt the XML structure of Interset with the structure of
INTELLECT.
Figure 19: Start page of Interset
INT-D13FINAL
Page 27 of 50
INTELLECT
IST-1999-10375
Figure 20: Interset’s news page
Figure 21: Product overview sorted for manufactures
INT-D13FINAL
Page 28 of 50
INTELLECT
IST-1999-10375
Figure 22: Product list in the basket
The pilot has been started at January only. The reasons are that the re-design of the web-pages has
been done by Interset and it caused much time. The last input came in December 2001 from Interset.
After that input Optinet had to adapt the XML structure of Interset with the common structure of
INTELLECT. Also the additional features like the help-desk system, basket functionality, shopping cart
etc. had to adapted and needed time. Before the Interset pilot started they collected experience with
the common prototype of INTELLECT. Another problem was the 2D configuration which should be
possible for this prototype. This mean a complete adaptation of the configurator and the 3D
visualisation. Therefore, additional time was needed. Nevertheless, the pilot is working since January
2002. There are still some open points which are the same as in the other pilots.
5.4 Conclusion
The workshop in Greece is planned for the end of February, based on the results of the outcome of
the existing pilots. This workshop is an important step (also for the Commission) to show that we are
using the chance to involve potential customers. Target companies are customers of Interset (or
similar users like Interset) or potential users of other areas (kitchen, furniture, garden, insurance
business). In addition some strategic partners to establish the value chain will be invited. Interset want
to use the prototype as a real product for their own web pages and they want to offer their customer
the features which they wanted.
INT-D13FINAL
Page 29 of 50
INTELLECT
IST-1999-10375
6 INTELLECT prototype
There were different INTELLECT prototypes available during the project. The first of all you can see at
nd
the Figure 23 and Figure 24, which has been presented in Brussels at the 2 review at May 2001. The
current surface you can find at the chapter afterwards. Within the prototype you can find the whole
functionality of the prototype which can be adapted to each pilot of the project on a simple way. Since
the end of 2001 also the new version of the software environment is available: Tomcat 4.0. The use of
these tools makes it necessary to implement a new application server. In addition this would be
needed for the integration of the mirroring with the whole shop. All software is licence are free (if you
replace Oracle by Postgres SQL for example).
6.1 First prototype
nd
The first prototype which has been shown in Brussels during the 2 review of the project was not a
stable software platform, because the different modules run on different machines and were not really
integrated in one platform. Also the surface was not very useful or got not a well design as you can
see in Figure 23 and Figure 24.
Figure 23: First start page which was presented in Brussels during the 2nd review
The next page is the catalogue of the products you can select for configuration. In the first prototype
we integrate only one product in three different categories. That means, you can select a computer as
a “slow”, “medium”, or “fast” one. After that choice it is possible to configure the product by the fact
that you can select different components which fits into the whole product. In this phase additional
features like real 3D view, shopping cart, user profiling, and different language support were not
integrated. But it was a big success that the different developed modules fit into one platform and play
with each other without big trouble.
INT-D13FINAL
Page 30 of 50
INTELLECT
IST-1999-10375
Figure 24: Product catalogue page from the first prototype
6.2 Current surface structure
The project INTELLECT has the requirement that we want to support different users (e.g. ISPs,
ASPs), who wants to offer their products to their customers. Therefore, we need a flexible user
interface which can be adapt on each user requirements which can be also changed during a project’s
lifecycle. Therefore, for the surface of the prototypes the e-shop pages are divided into several areas.
The requirements for a highly customisable localisable user interface are:
- All content must be translatable and customisable (the static textual content of UI and the
dynamic content coming from the dB).
- All names (action names, attribute names,....) and their explanation (=description) must be
translatable and customisable, (e.g. the attribute "date" appears on a German page as title of
a column like "Datum")
- The translation or customisation of any name, any explanation of a part of that object
(attribute,....) or it’s icon can be made in a central place just once and must be reflected
immediately and consistently in all the places where this name is shown
- Presentation mechanisms (there are just a few, e.g. Tree View, List View, Detail View,
Presentation of Actions (Pull-Down Menus, Pop Up Menus), Choice of alternatives....) must be
used consistently in the whole USI. The Look of each presentation mechanism shall be
customisable in one central place (e.g. bullets or “+” symbol for tree view)
- Consistent appearance of an object, wherever I see it. Restrict what I see from an object for a
specific appearance of that object in a USI
- The general look can be changed / customised in a central place just once and must be
reflected immediately and consistently in all the places (e.g. Colour, Font, ...)
- It should also be definable, which presentation mechanism is used if there are alternatives
(e.g. possible actions presented as pop up menus or pull down menus; choose of alternatives
via combobox or radiobuttons)
- Support of and specific customisations for different client technologies (WML, HTML,...)
INT-D13FINAL
Page 31 of 50
INTELLECT
IST-1999-10375
Navigation:
NEWSFLASH:
MainMenu
MainMenu
Headline
New Bike Race in Vienna
Special Brakes available
Bla Bla Bla
Tralalalalala
MainMenu
MainMenu
SubMenu
SubMenu
SubMenu
MainMenu
MainMenu
LOGO 2
Date
1.7.00
2.6.00
1.6.00
9.5.00
Click on the News article to see details below!
LOGO 1
SubMenu
Location
Vienna
Oslo
Rennes
Bremen
Selected News article:
New Bike Race in Vienna
Picture 2
Vienna, 1.7.00:
Bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla
Order Tracking
You already ordered
products from us
and want to know, if
it has already been
delivered?
Log in here:
User:
Password:
Special offer of this week:
Get the new Shimano Break for only $ 245,-!!!!
Click here to get details....
Picture 1
Forgot your
password? Click
here!
Figure 25: Surface areas for XML/XSL support
The customisation of the e-shop has two different aspects: one is the overall appearance of the shop
which has to be defined once before the shop is on line and the second is part of the contents which
can be variable. The difference between these two is the method. The appearance for the e-shop can
be defined in a configuration file, the content can be changed with the administration tool. The
following parameters can be changed:
6. for the appearance:
a. Colour
b. Font
c.
Logo
d. Languages and currencies, how and where to switch
e. Sound
f.
Layout: where are the navigation toolbars, the frames for the
main information etc.
g. Navigation possibilities: links to other sites, menu items
h. Appearance of menus: pull down, pop up, choice of
alternatives with radio buttons or combo boxes
i.
Use of flash / or not
j.
appearance of the catalogue structure
k.
Search possibilities, e.g. for manufacturers, categories or
products, only with headword
l.
Payment methods
m. General Trading Conditions
n. Delivering methods
7. for the content:
INT-D13FINAL
Page 32 of 50
INTELLECT
IST-1999-10375
a. Fields for the customer data
b. Catalogue structure, e.g. new categories
c.
Attributes for new product categories
d. Changes of the navigation, e.g. new menu items
e. The configuration of the shop should be as flexible as
possible but if the shop operator prefers a static configuration,
it might be a good idea to configure all items with the
configuration file.
Pages like in Figure 25 can be realised in many ways, the classical approach to achieve this would be
to code every page in the shop manually, that means the HTML with it’s included dynamic tags would
be individually edited. If there is another merchant, the pages can be copied and changed to the other
merchant’s needs. The back-end functionality will not be changed – they will only be used or not.
This approach includes the following two major ideas:
•
Using XML (eXtended Markup Language), XSL (eXtended Stylesheet Language) and DTD
(Document Type Definition) as basis to support the requirements of different merchants and
different client technologies.
•
Object centred GUI definition, customisation and implementation
•
Define USI representation not for a page or a frame, but define them per object, which has to be
represented and can be reused wherever the object appears in which representation ever.
•
Choose the objects you want to see in a frame / on a page. Place them. Choose the presentation
mechanism (list view, detail view, combination of list and detail view,...). Restrict the default
appearance if necessary
•
The View of the object can be different for different user roles (e.g. the view of an object is
different, if an administrator, help desk agent or a normal customer gets the page)
The page creator can use an XML-based page description language, where he defines the parting of
the page into different areas (frames, boxes,....) – this step is similar to defining the frameset for a
multiframe web-page – and then define an object and it’s presentation mechanism (e.g. Product
Details or Product List), that is responsible for producing the content for this area.
6.3 Second prototype
The Figure 26 shows the end result of the surface of the INTELLECT prototype. This is an common
surface which will be used for common advertisements or project presentations. All features are
available together, while that is not the case at the pilot prototypes, because of the different
requirements. The configuration is only possible with abstract 3D objects as you can see in Figure 27.
The session ID in Figure 26 helped us to recognise if the same user is shopping or changed during the
session.
The features which can be used are:
-
Configuration of three products of the database
-
Login
-
User profiling by a login template and the same session ID
-
Help-desk functionality by the integration of the third party tool NetMeeting
-
Basket
-
Shopping Card
-
Catalogue
-
Multi-language support
-
Order processing
-
Visualisation of abstract 3D objects
-
XML/XSL surface for fast adaptation of new requirements
INT-D13FINAL
Page 33 of 50
INTELLECT
IST-1999-10375
Figure 26: Surface of the INTELLECT system
Figure 27: Virtual Reality Java Applet Window
Figure 28 shows the catalogue page which includes additional one scooter. All information you see
come from the database as scooter description, producer logo, and price. There is no static
information more available against the first prototype. On the right hand you see the help-desk feature
which includes a videoconference windows if there is an agent available on the other site. Here you
can see only the NetMeeting logo, but it is direct integrated into the web page.
INT-D13FINAL
Page 34 of 50
INTELLECT
IST-1999-10375
Figure 28: Product catalogue of the INTELLECT prototype
The last figure of the current prototype shows the user profile template, which must be used to get a
login/password information by the provider of the e-shop system. This template can be adapt to
different user on a simple way. Also here you can get help directly or look at your basket.
INT-D13FINAL
Page 35 of 50
INTELLECT
IST-1999-10375
Figure 29: Entry template for the user profile
6.4 Common open issues
Regarding the development and integration there are still open points which will be solved after the
project time if the prototype of INTELLECT will be a real product. Therefore we can divided the needs
of the future into the different modules of INTELLECT:
1. eShop (Optinet)
a. Producer info (by the users)
b. My configuration (add to basket, delete configuration, configure configuration)
INT-D13FINAL
Page 36 of 50
INTELLECT
IST-1999-10375
c.
Pictures and content (from the user of INTELLECT)
d. Community building
e. Merchant support (is foreseen)
f.
Developing an administration tool for the e-shop products
2. Virtual Reality (Atlantide)
a. Get 3D data from the users or if that is not possible integrate “dummy” data (very
important for the pilots and the next review)
i. VRML.JAR file is necessary in the first step for the current pilots for two
products; the current version is not sufficient for the pilots!
ii. 2D photographs from the users
b. Avatar integration/extension
c.
Extend the 3D visualisation with animation of the Avatar
d. 2D visualisation of the products (bigger effort as the 3D view, because of the more
pictures which are needed)
e. Integration of the 3D applet within the web-site
f.
Better and more efficient client adaptation
3. Help-desk (Anecon)
a. Integration of the mirroring mechanism in Tomcat 4.x
b. Integration of the administration tool
c.
Efficient handling of incoming calls
4. Order processing (Anecon)
a. Handling of orders for different suppliers
6.5 Conclusion
The common prototype of INTELLECT is stable enough to work in different environments for different
users with different requirements. Therefore, the project members want to set-up a real product after
the project’s lifecycle. To get a real product, there are still some open points available which have to
be developed if such a product will be successful on the market. A real problem is the 3D visualisation
from the user and the provider point-of-view, because it is not possible to get 3D pictures direct from
the producer as we got the experience in our project. Also it is not possible to get this information by
the provider (e.g. the format of the 3D data is not the same, there are no 3D data available). Therefore
the offering company has to create this 3D data on their own. That is in many cases time critical. On
the other hand, the end-user clients must be prepared for the 3D view, because Java3D is not
integrated in today’s browsers. That is not very comfortable at the moment. Hopefully new browser
version will support this technology, otherwise it will not be successful.
Finally the software versions were not stable enough in the past to create a real product. That must be
changed in the near future. The handling with the application server is also not fast enough. Bigger
bandwidth and faster server platform should be necessary for the provider, but also for the end-users.
The results you can find in detail in deliverable D15.
INT-D13FINAL
Page 37 of 50
INTELLECT
IST-1999-10375
7 Handbook
This description will give an overview about the complete architecture and the handling of the different
modules.
7.1 Architecture
The INTELLECT consortium provides an enhanced eShop system including all practicable electronic
commerce features, and offering a suitable and realistic representation of the products. The
INTELLECT application contains five modules:
1. The eShop module takes care of the general functionality of an e-commerce system (basket,
catalogue, secure communications, localisation, multimedia presentations, …).
2. The Virtual Reality module provides 3D visualisation of the product, and enables the
customer to configure its own product by choosing each of the components.
3. The Configuration module manages the configuration possibilities.
4. The Help-desk provides on-line help to the customer, using features like chat, voice over IP,
and videoconferencing.
5. The Order-processing module manages the orders, and implements the interface between
the INTELLECT application, and the back-office systems.
The INTELLECT product is based on a three tier (layer) design. The next figure provides an overview
of the software products and tools, which were necessary for the development of the prototype of
INTELLECT. On the one hand, the prototype uses open source products as it's underlying backbone.
On the other hand, third party products are used for direct real-time communication via NetMeeting or
security connectivity via SSL. In addition, commercial products regarding databases are used.
Therefore the architecture can be devided into three tiers on the server site:
1. JBoss (Tier 1): The JBoss/server is an open source, standards-compliant, Enterprise Java
Beans (EJB) application server implemented in 100% pure Java code. The JBoss community
of over 500 developers world-wide is working to deliver the full range of J2EEtools as the
premier enterprise Java application server for the Java 2 enterprise edition platform. The
JBoss/server and complement of products are delivered under a public license. With 1500
downloads per day on average, JBoss/server is the fastest growing J2EE based server worldwide.
2. Tomcat (Tier 2): Tomcat is the reference implementation for the Java Servlet 2.2 and Java
Server Pages (JSP) 1.1 technologies. It includes the web server technology and offer this
functionality base for the prototype.
3. Cocoon (Tier 2): Cocoon is a 100% pure Java publishing framework that relies on new W3C
technologies (such as DOM, XML, and XSL) to provide web content. The Cocoon project aims
to change the way web information is created, rendered and served. The new Cocoon
paradigm is based on the fact that document content, style and logic are often created by
different individuals or working groups. Cocoon aims for a complete separation of the three
layers, allowing the three layers to be independently designed, created and managed,
reducing management overhead, increasing work reuse and reducing time to market.
4. Oracle (Tier 3): The database Oracle8i standard edition enables business to cost-effectively
develop and deploy Internet-based solutions. Oracle8i includes native support for technologies
like SQL, XML, and Java that have become the standards on which today's e-businesses are
built.
For the independence of the end-user presentation and functionality, the project decided to use Java
Server Pages (JSP) technology which allows web developers and designers to rapidly develop and
easily maintain, information-rich, dynamic web pages that leverage existing business systems.
INT-D13FINAL
Page 38 of 50
INTELLECT
IST-1999-10375
As part of the Java family, JSP technology enables rapid development of web-based applications that
are platform independent. JSP technology separates the user interface from content generation
enabling designers to change the overall page layout without altering the underlying dynamic content.
JSP technology uses XML-like tags and scriptlets written in the Java programming language to
encapsulate the logic that generates the content for the page. Additionally, the application logic can
reside in server-based resources (such as Java Beans component architecture) that the page
accesses with these tags and scriptlets. Any and all formatting (HTML or XML) tags are passed
directly back to the response page. By separating the page logic from its design and display and
supporting a reusable component-based design, JSP technology makes it faster and easier than ever
to build web-based applications.
Servlet engine
Client’s
browser
EJB engine
database
Xsp
Cocoon
Admini
strative
tools
EJBs
Servlets & JSP
Tomcat
JBoss
Oracle
Application server
Server side
network
Figure 30: INTELLECT's system architecture
JSP technology is an extension of the Java Servlet technology. Servlets are platform-independent,
100% pure Java server-side modules that fit seamlessly into a web server framework and can be used
to extend the capabilities of a web server with minimal overhead, maintenance, and support. Unlike
other scripting languages, servlets involve no platform-specific consideration or modifications; they are
Java application components that are downloaded, on demand, to the part of the system that needs
them. Together, JSP technology and servlets provide an attractive alternative to other types of
dynamic web scripting/programming that offers platform independence, enhanced performance,
separation of logic from display, ease of administration, extensibility into the enterprise and most
importantly, ease of use.
Java Beans component architecture is the platform-neutral architecture for the Java application
environment. It can develop or assemble network-aware solutions for heterogeneous hardware and
operating system environments, within the enterprise or across the Internet. Java Beans component
architecture extends "Write Once, Run Anywhere" capability to reusable component development. In
fact, the Java Beans architecture takes interoperability a major step forward - every code runs on
every operating system and also within any application environment. A beans developer secures a
future in the emerging network software market without losing customers that use proprietary
platforms, because Java Beans components interoperate with ActiveX. Java Beans architecture
INT-D13FINAL
Page 39 of 50
INTELLECT
IST-1999-10375
connects via bridges into other component models such as ActiveX. Software components that use
Java Beans APIs are thus portable to containers including Internet Explorer, Visual Basic, Microsoft
Word, Lotus Notes, and others. The JavaBeans specification, which was completed ahead of
schedule, defines a set of standard component software APIs for the Java platform. The specification
was developed by Sun with a number of leading industry partners and was then refined based on
broad general input from developers, customers, and end-users during a public review period.
The Java Servlet technology provides web developers with a simple, consistent mechanism for
extending the functionality of a web server and for accessing existing business systems. A servlet can
almost be thought of as an applet that runs on the server side - without a face. Java servlets have
made many web applications possible. Servlets are the Java platform technology of choice for
extending and enhancing web servers. They provide a component-based, platform-independent
method for building web-based applications, without the performance limitations of CGI programs. And
unlike proprietary server extension mechanisms (such as the Netscape Server API or Apache
modules), servlets are server- and platform-independent. This leaves you free to select a "best of
breed" strategy for servers, platforms, and tools.
Servlets have access to the entire family of Java APIs, including the JDBC API to access enterprise
databases. Servlets can also access a library of HTTP-specific calls and receive all the benefits of the
mature Java language, including portability, performance, reusability, and crash protection. Today,
servlets are a popular choice for building interactive web applications. Third-party servlet containers
are available for Apache Web Server, iPlanet Web Server, Microsoft IIS, and others. Servlet
containers can also be integrated with web-enabled application servers, such as BEA WebLogic
Application Server, IBM WebSphere, iPlanet Application Server, and others. JSP technology is an
extension of the servlet technology created to support authoring of HTML and XML pages. It makes it
easier to combine fixed or static template data with dynamic content.
7.2 Installation Guide of the client’s software
The Java 3D API Version 1.2.1_02 Maintenance Release Implementation is available for download.
The Java 3D 1.2 API is a set of classes for writing three-dimensional graphics applications and 3D
applets. It gives developers high level constructs for creating and manipulating 3D geometry and for
constructing the structures used in rendering that geometry. Remember, before installing Java 3D you
will first need to install the Java 2 environment. In addition to several bugs fixed and better
performance, the Java 3D 1.2.1 implementation also contains these additional features:
•
Documentation For Utility Classes
•
Example programs changed to use new Orbit Behavior classes
Java 3D delivers Java's "write once, run anywhere" benefit to developers of 3D graphics applications.
Java 3D is part of the JavaMedia suite of APIs, making it available on a wide range of platforms. It
also integrates well with the Internet because applications and applets written using the Java 3D API
have access to the entire set of Java classes.
The Java 3D API draws its ideas from existing graphics APIs and from new technologies. Java 3D's
low-level graphics constructs synthesize the best ideas found in low-level APIs such as Direct3D,
OpenGL, QuickDraw3D, and XGL. Similarly, its higher-level constructs synthesize the best ideas
found in several scene graph-based systems. Java 3D introduces some concepts not commonly
considered part of the graphics environment, such as 3D spatial sound. Java 3D's sound capabilities
help to provide a more immersive experience for the user.
Java 3D was designed with several goals in mind. Chief among them is high performance. Several
design decisions were made so that Java 3D implementations can deliver the highest level of
performance to application users. In particular, when trade-offs were made, the alternative that
benefited runtime execution was chosen.
Other important Java 3D goals are to
-
Provide a rich set of features for creating interesting 3D worlds, tempered by the need to avoid
nonessential or obscure features. Features that could be layered on top of Java 3D were not
included.
INT-D13FINAL
Page 40 of 50
INTELLECT
IST-1999-10375
-
Provide a high-level object-oriented programming paradigm that enables developers to deploy
sophisticated applications and applets rapidly.
-
Provide support for runtime loaders. This allows Java 3D to accommodate a wide variety of
file formats, such as vendor-specific CAD formats, interchange formats, and VRML97.
The installation guide for the client preparation will be published on the web-site of INTELLECT. If
interested people want to play with the prototype, a direct link to our INTELLECT server is here
available, which you can use. But keep in mind it is only a prototype, what means that we have to go
on with the development of further features, embed more user requirements, and reach a more stable
status as now. Therefore it is current only a beta version, which is maybe sometimes not available
online.
You need at first a 3D Java extension to see the 3D product and to be able to configure it. Therefore,
the client must have installed:
1. Install the java plugin (with the java JRE 1.3.1): file j2re-1_3_1-win-i.exe (8,1 Mbyte)
2. Install the Java3D software (not a beta version): file java3d-1_2_1_01-win32-opengl-rt.exe
(2,5 Mbyte) for Windows 98/NT/2000 (also a Solaris version is available)
3. Ensure that it does install in the right Virtual Machine (VM) the one that is used by the plug-in.
(usually c:\program files\javasoft\jre)
4. Have only one Java Run Environment on your computer!
5. Add the vrml97.jar (317 Kbyte) to the classpath of the client. This can be done by several way
either to the classpath in the autoexec.bat or in the /lib/ext directory of the right VM (ONLY
AVAILABLE FOR BRUSSELS AND INTELLECT PROTOTYPE NOW!!!)
After the short installation phase you can play with the different available prototypes!
7.3 Product Data Model
Primary goal during the specification of the INTELLECT Product Data Model was flexibility in respect
to the different kinds of products that can be categorised and simplicity of design in order to minimise
the overhead imposed by the model itself. Product data can be entered into the INTELLECT database
either manually through an application (see Figure 33) designed to be used by the knowledge
engineer administering the knowledge base or in a bulk fashion i.e. from data exported from a backoffice.
The structure consists of the following entities:
1. Pre-configured products
2. Products
3. Component types
4. Components
5. Component categories
Products represent a package sold to the customer. This can be either a single object or a
combination of components comprising a specific variant. Products contain one or more list of
components. Lists are meant to support structuring of related components. An example of a product
with more than one component list is kitchen furniture. The equipment for a whole kitchen could be
specified as one product that is clearly structure in one or more related groups of components (i.e. a
table and chairs, various cupboards, etc.). A computer on the other hand will most likely contain only
one component list for all components. The configuration of the component lists and the categorisation
of the components is up to the administrator’s discretion.
INT-D13FINAL
Page 41 of 50
INTELLECT
IST-1999-10375
Hard
Categories
Soft
Categories
Component
Types
Components
HardDisks
Mainboards
AVEquipment
High-End
Low-End
IBM
DCAS3440
Maxtor
4567
IBM
DORS3240
U2W, 8 GB,
5400rpm
U, 4 GB,
5400rpm
UW, 2 GB,
5400rpm
Figure 31: Component types, Components and Categories
Products exist furthermore in one of two variations, pre-configured products and new products. Preconfigured products are the ones used to generate the product catalogue and are used as templates
for generating new variants. Every time a user decides to configure a product, a copy of the preconfigure version there of is made. The new product is then modified to produce the desired variant.
The differentiation between the two kinds of products is required in order to prevent modification of the
original designs.
Component types represent a certain type of part, possibly a specific model (i.e. the IBM DCAS2340
hard-disk). A component type is used to define the attributes related to this object. A dynamic attribute
mechanism allows for arbitrary types and quantities of attributes. It is important to note that attributes
of component types have not values, they simply provide the infrastructure needed for the usage of
attributes in a specific product.
Components on the other hand represent concrete elementary parts sold either separately or as part
of a product. Such components are instances of a specific component type and contain concrete
values for the defined attributes. A component for a specific type of hard disk (specific component
type) i.e. would have concrete values for attributes like size, speed, form-factor etc.
INT-D13FINAL
Page 42 of 50
INTELLECT
IST-1999-10375
<<Interface>>
IProduct
updateCurrentProductKey()
playMultimedia()
setPrice()
getPriceOfAllComponents()
getManufacturer()
showDetails()
PreconfiguredProduct
createNewProduct()
NewProduct
customiseProduct()
show3D()
getComponentList()
getPossibleComponents()
changeComponent()
ComponentCategoryConstraint
Product
ComponentCategory
price : Integer
availibility : Boolean
productKey : Integer
productName : String
taxrate : Double
1
CategorySpecificData
CategoryType : String
playMultimedia()
getPriceOfAllComponents()
showDetails()
setPrice()
updateCurrentProductKey()
getManufacturen()
ComponentConstraint
1..*
ComponentList
Item
ComponentType
id : Integer
multimediaUrl : String
configurationContrains
manufacturerName : String
manufacturerId : Integer
1..*
updateItem()
deleteItem()
getManufacturerName()
getManufacturerLogo()
showInfo()
createItem()
componentTypeName : String
emptyComponentAttributes : HashTable
IComponent
getComponentTypeName()
setComponentTypeName()
componentKey : Integer
componentName : String
filledcomponentAttributes : HashTable
componentPrice : Integer
availibility : Boolean
setAttributesType()
getAttributesType()
ComponentTypeattribute
name : String
valueType : String
setName()
setValueType()
getName()
getValueType()
FilledComponentAttribute
ComponentAttribute_Integer
ComponentAttribute_Float
ComponentAttribute_String
attributeValue : Integer
attributeValue : Float
attributeValue : String
setValue()
setValue()
setValue()
Figure 32: INTELLECT product data model class-diagram
INT-D13FINAL
Page 43 of 50
INTELLECT
IST-1999-10375
Figure 33: Tree view of a complete product
Component categories exist in two variants hardware categories and soft categories. Hard categories
represent a whole group of components that have the same basic function (i.e. all hard-disks), soft
categories define configuration preferences and general criteria. Both types are used to reduce the
number of components that are suitable. Soft categories are also used to define the “soft” criteria
suitable for this product domain (see Figure 31). The knowledge engineer designing the knowledge
base for a new Configurator has to decide what groups of components are necessary in order to
provide the end-user with a sufficient set of options during configuration.
PCI Card,
Elsa Erazor
Equality
Constraint (=)
ConnectionInput=PCI
Mainboard,
Asus xyz
ConnectionOutput=PCI
Figure 34: Constraints
Constraints between attributes of specific component types enforce “construction” rules (see
Figure 34). Constraints are operators that can be defined nearly arbitrarily and can be used to support
new configuration behaviour. The Attributes “ConnectionImput” and “ConnectionOutput” together with
the equality constraint i.e. are used to define which components fit together physically and what sort of
interfaces each component type requires or makes available.
Due to the modular and extensible design of the INTELLECT Configurator, it is relatively easy to add
new Constraint types (i.e. bigger than, smaller than) that make new kinds of configurations possible.
Products used for testing in the first version of the Configurator (scooters and computers) were fully
modelled using only the equality constraint and appropriate Component Categories.
INT-D13FINAL
Page 44 of 50
INTELLECT
IST-1999-10375
7.4 User Handling
The VR module is the main Configurator user-interface. It aims to present the product in a way that is
as realistic as possible. This is achieved through a product visualization in 3D and interactive
navigation in 3D space. The user can interact with the product: turn, zoom, select and configure a
component; the Configurator supplies the possible configurations. The 3D view of the products is
obtained by assembling 3D models of its components stored in VRML files. This functionality is
implemented with the help of two programmes:
The manager application is intended for the shop operator, which will be in charge of the management
of the 3D data, and the assembling rules definition.
The user application is intended for customer use, and will mainly offer a 3D view of the product,
which the customer will be able to view in several positions, and to configure according to his wishes.
The use of Java3D (the 3D API for Java) allows the rendering of a 3D world in a Java application or a
Java applet. Java3D provides a collection of high-level constructs for creating, manipulating and
rendering 3D geometric objects in a virtual universe. The Java3D world corresponds to a scene graph,
which is an arrangement of 3D objects in a tree structure that completely specifies the contents of the
virtual universe, and the way it is rendered. VRML files can be loaded and added to a Java3D
universe thanks to the VRML97 library, defined by the VRML-Java3D working group.
7.4.1 Managing the VR representation of products
A product is composed of several components; each has a 3D model described in a VRML file. To
view the product, we have to assemble correctly the components. To define the assembling rule
between two components of a product, an “Anchor” is needed for each component. This anchor is
composed of an origin and an orientation relative to the origin of the scene. When the two components
are assembled, their two anchors correspond exactly. The two anchors for an assemblage have the
same name. This mechanism corresponds to the “connectionInput” and “connectionOutput” attributes
used by the Configurator.
<<include>>
AddNewAnchor
ViewAnchor
<<include>>
EditAnchor
<<communicate>>
<<include>>
Manager
SelectAnchor
<<communicate>>
MoveAnchor
Manager
<<communicate>>
SuppressAnchor
Assemble
SaveComponent
Figure 35: Use Case
INT-D13FINAL
Page 45 of 50
INTELLECT
IST-1999-10375
The shop operator has to define the two anchors for each assemblage in the manager application, and
then the assemblage can be calculated by composing the transformations corresponding to the
anchors. As shown on Figure 35, the manager (the shop operator) has the possibility to load a single
component, and manage its anchors. When the manager loads a component, the application shows
its 3D model and its existing anchors in the Java3D view (ViewAnchor). The anchors are also
displayed in a list. The manager can select an existing anchor in the list, or in the visualisation area
(SelectAnchor), but only if he is in the interaction mode (see Navigation); the selected anchor appears
in a different colour than the others; it can be edited in a separate window (EditAnchor). While an
anchor is edited, its values can be modified in the edition window or by “drag and drop” in the
visualisation area (MoveAnchor), but in order to avoid confusions, the manager is not allowed to select
another anchor until the edition window has been closed. The manager also has the possibility to
create a new anchor (AddNewAnchor), which is instantiated with default values. He can also suppress
an existing anchor (SuppressAnchor).
Figure 36: Anchors for the assemblage between a frame and a wheel
To choose the name of an anchor, the manager will have to select the second component of the
assemblage from the existing components and then choose one of its anchors, if it has already been
created, or define a new name if the anchor does not exists yet on the other component.
The manager will have to save the component (SaveComponent) if he wants its modifications to be
taken in account. He if does not, and tries to exit the application, a dialog frame will ask him for
confirmation, and give him the choice to save or not.
The manager has the possibility to view the results of the assemblage (whether the component has
been saved or not) thanks to the Assemble functionality. He will have to choose from a list of available
components, including the one which is edited, the components he wants to assemble. The
application will load every component, read the anchors list and calculate the corresponding
assemblage. Once all the anchors needed for a product have been placed, the manager will ask the
configuration module if its product is correct (to be sure he hasn’t forget a component or an anchor), if
yes, he has the possibility to save this product as a pre-defined product.
The navigation possibilities are the same in the customer and manager applications. Navigation
includes everything that allows the user to see the object (product or component) from a different point
of view. Some usual navigation possibilities in Virtual Reality applications are more or less userfriendly, depending on the viewed scene. Navigation using the keyboard for example (←, ↑, →, ↓) are
mostly used in games or worlds the user can walk into; but in our application this navigation type
become very unfriendly; turning around an object is very difficult, and it is better way for the user to
manipulate (translate or rotate) directly the object, and make it move (MoveObject).
INT-D13FINAL
Page 46 of 50
INTELLECT
IST-1999-10375
Figure 37: VR Manager Application
7.4.2 VR Graphical User Interface for the customer
The customer sees in the main window the pre-defined product he has chosen in the eShop, and is
able to interact with it and manipulate it in various ways.
Three modes are available for the user: translate, rotate and interact. The translate mode allows the
user to use the mouse to translate the object in the current visualisation plan, the rotation mode allows
the user to rotate the object with the mouse, and the interaction mode disables navigation with the
mouse (but not the other navigation means), so that the user can use the mouse to interact with the
scene (select an anchor or a component, or move an anchor).
To make it easier for the user who may not be used to use the mouse for moving objects, the
application calculates a list of predefined ones (Face, Back, Right, Left, Up, Down), using rotations
from the initial viewpoint. Another viewpoint allows the user to see all the objects of the scene.
The user also has the possibility to zoom in or out with the zoom functionality. He can give directly the
zoom value, increment or decrement the existing one, or reset the zoom. All these navigation
possibilities allow the user to view the object in several points of view even if he isn’t very used to
navigation, and to move objects with the mouse, which may seem difficult for a novice, but which bring
the sensation of manipulating the object.
INT-D13FINAL
Page 47 of 50
INTELLECT
IST-1999-10375
8 Conclusion
After the first pilot has been started the modules were improved continuously. That means new user
requirements did arise during the pilot phase and must fulfil from the developers, handling limitations
need a new adaptation, missing features had to extend the prototype, and a stable platform had to
created for testing and evaluation.
Nevertheless there are still some points missing regarding the modules after the pilot phases, like
1. eShop: SSL integration, creating of XML pages for HiTEC, new backend functionality
regarding the end-users requirements, and an administration tool
2. Virtual reality: Integration of the 3D window into the web surface, an avatar for animations,
2D visualisation into the configurator, and producing 3D data
3. Configuration: 3D data is missing for the configuration database and some input for the
database at all
4. Help-desk: There were no mirroring available for the pilots, because of Tomcat 4.x had to be
integrated into JBoss, but Tomcat 4.x was only available since the end of the year of 2001.
5. 3D data: We need the 3D data for the configuration. That means problems e.g. for Interset
because they really don't need it and in addition the implementation effort at the client
computer is too high at the moment. The other end-users has the same problems. Only HiTEC
needs 3D visualisation really. And they didn’t get this data it from their producer.
6. Product presentation: The 2D configuration was selected for the pilots of Interset and
Blauwerk. But the integration into the 3D module and into the configurator is still missing.
In the meantime, the prototypes are stable enough to seriously invite customers to present the system
to them now. But the project partners still need additional work of the different modules after the
project’s end if they want to create a real product. INTELLECT had set-up a list of maintenance points
concerning all modules. That means requirements for up-dates, bug fixes, additional requirements and
so on. The development partners of INTELLECT used the pilot phase to collect new experience about
their developed system. Also they were in contact with the end-users continuously to find out limits,
usability, efficient handling, and problems. After all they got a stable prototype which consist of
different modules which are very flexible. The end-users got a big support from developers and set-up
their new designed web-pages with new content and features. They will support the product also after
the projects lifecycle to bring it into the market and present real worked demo platforms. Against all
missing features, the project INTELLECT was a success story for all partners within the project.
INT-D13FINAL
Page 48 of 50
INTELLECT
IST-1999-10375
9 Annex
9.1 Pictures from the whiteboard from Blauwerk’s prototype
Figure 38: eShop structure (navigation) with the main interest of products
INT-D13FINAL
Page 49 of 50
INTELLECT
IST-1999-10375
Figure 39: Product site of a choosen scooter with applet window and video streaming
Figure 40: 3D visualisation with visible configuration, actual prices, and animation
Figure 41: The other web sites without products
INT-D13FINAL
Page 50 of 50

Deliverable (public)

Transcription

Similar documents

Intellect-powered security at Abu Dhabi National Oil Company

Investors Presentation - Intellect Design Arena Ltd

Froggy Drawing handout2 - Mid Mon Valley Transit Authority

4 Neal Bastick

Smoke Signals, Oct 2010

Deliverable (public)

KOROBRI LA HOMSTED Danny Marmina Jentian

Deliverable (public)

Judge Me By My Past.

Cover