Volkswagen Car Configurator

Volkswagen Car Configurator Robert Konstanzer, Daniel König, Irina Andrei Visual Requirements Engineering

Prof. Harald Reiter, Thomas Memmel

Abstract

This paper was developed in connection with the lecture “Visual requirement engineering for the inter-action design” of Professor Harald Reiterer and his graduate student Thomas Memmel at the University of Constance. The work is a case study that defines a visual specification of the Volkswagen car con-figurator, with the help of iRise Studio, an easy-to-use application definition tool used by business experts to quickly assemble functionally rich simulations of Web-based applications. iRise Studio is used for portals, new custom applications, enhancements to existing systems and packaged software and “is dedicated to bridge the communication gap between business and IT by dramatically improving the process of defining business applications.” (iRi07)

2 Robert Konstanzer, Daniel König, Irina Andrei

Table of Content

1 Introduction 3 1.1 Why Visualize Requirements......................................................................................3 1.2 Proceeding...................................................................................................................3

2 Requirement Engineering Process 4 2.1 Requirements Election and Analysis...........................................................................4 2.1.1 Usability Goals............................................................................................................4 2.1.2 User Analysis ..............................................................................................................6 2.1.3 Expert Walkthrough....................................................................................................7 2.2 Requirements Specification ........................................................................................7 2.3 Requirements Validation.............................................................................................8 2.4 Requirements Management.........................................................................................9

3 iRise Prototype 10 3.1 Usability Goals For The New VWCC.......................................................................10 3.2 Concepts....................................................................................................................11 3.2.1 Welcome Page...........................................................................................................11 3.2.2 Comparison ...............................................................................................................13 3.2.3 Choice of type ...........................................................................................................13 3.2.4 Motor.........................................................................................................................14 3.2.5 Colour Combination..................................................................................................15 3.2.6 Special Equipment (Extras).......................................................................................17 3.2.7 Your Car....................................................................................................................19 3.3 Benchmark of the new VWCC..................................................................................21

4 Summary And Outlook 23

5 References 24

6 Appendix 24 Appendix A – used Tools........................................................................................................24 Appendix B – Field Report .....................................................................................................25 Appendix C – iDoc from the existing to the new CC..............................................................25

Volkswagen Car Configurator 3

1 Introduction

1.1 Why Visualize Requirements In the industry there is a gap between the skills and responsibilities of the stakeholders. Rapid Prototyping is one method to bring people with different skills together much earlier within the development lifecycle. But there is still a lack; with static wire frames there is no ability to interact with the interface.

To remove this limitation user experience professionals use simulation technology to visual-ize projects, they are able to produce requirements that are much clearer than those generated through a traditional requirements process. In fact, there are just a few tools at the market that help business analysts, one of them is iRise.

1.2 Proceeding The primary goal of the course was to define a car-configurator using a visual requirement specification model. Our team therefore adapted the standard requirement engineering proc-ess using elements of extreme programming and usability engineering. As an example we used the car-configurator of Volkswagen.

All artefacts, as well as the visual specification itself were produced using iRise Studio in conjunction with other screen-design programs. The second goal of the course was to find out whether iRise was an appropriate tool that supports a visual requirements engineering process.


2 Requirement Engineering Process

Figure 1: Requirements Engineering Process

Figure 1 shows the requirements engineering process, which was used to manage our defini-tion of our new VWCC. The different phases of the process and the way we used them is described in the subchapters.

2.1 Requirements Election and Analysis In the first phase we selected guidelines from the EN ISO 9241-10 (Ergonomic requirements for office work with display terminals - Part 10: Dialogue principles), which seemed suitable for this application at the automotive domain and we did a user analysis. After that we did an expert evaluation of the existing VWCC to identify usability issues and best practices. The usability issues and best practices were then matched with the identified guidelines and were documented. The result was a first documentation of our requirements.

2.1.1 Usability Goals The EN ISO 9241-10 [USE07] Ergonomic requirements for office work with display termi-nals - Part 10: Dialogue principles has been renumbered in August 2006 under ISO’s revi-sion and restructuring programme (ISO 9241-110:2006 Ergonomics of human-system inter-action -- Part 110: Dialogue principles), however the content remained the same. This part of the ISO 9241 is a set of usability heuristics that applies to the interaction of people with in-formation systems (it is based on earlier German standards).


Interaction is called dialogue and describes seven principles altogether for dialogues. These seven principles are:

1. Suitability for the task

The dialogue should be suitable for the user’s task and skill level.

2. Self-descriptiveness

The dialogue should make clear what the user can do next.

3. Controllability

The user should be able to control the pace and sequence of the interaction.

4. Conformity with user expectations

The interface should be consistent and meet the users expectations.

5. Error tolerance

The interface should be able to react reasonable on all user inputs.

6. Suitability for individualisation

The Interface should be able to be customised to suit the user.

Figure 2: Usability Goals in iRise Studio


At this point we used pages of iRise Studio to document our usability goals for later presen-tation. Each principle got it's own page; thus we used iRise like a kind of Microsoft Power-Point.

2.1.2 User Analysis Due to the project scope there was no time to interview customers, nor did we have data about the behaviour or characteristics of Volkswagen's customers. We therefore did our own user analysis in which we tried to identify the users characteristics and capabilities.

Volkswagen has a big array of products. They have cars in the city segment, family cars, sport utility vehicles, vans, upper-class cars, sports cars and so on. Defining the typical cus-tomer of Volkswagen is not easy at all. It can be a student, family father, pensioner or the prime minister. Therefore we defined capabilities, which influence the usage and the inter-face of a car-configurator (Figure 3).

novice

Computer knowledge

expert

Car knowledge

Figure 3: VWCC User Groups

The first capability that a user can have or not is profound knowledge about cars. A user that does not know much about cars should not need to be bothered with questions he cannot an-swer. Specific vocabulary must be explained so that the user can decide if he needs a certain feature or not. Type and colour of a car might be more important to such a user than techni-cal details. A user with great experience in the automotive field might want to configure his car in much greater detail. The interface should be built to support both user groups.

The second capability, which influences the usage of a car-configurator, is the user’s knowl-edge in using computers. An experienced computer user is accustomed to complex interfaces while a novice may even have problems using the mouse.

Two simplify things a little bit we define that users with good knowledge about cars are also advanced computer users, thus we will call them “experts”. Users with little knowledge in both will be called “novices”.


2.1.3 Expert Walkthrough With the background of the usability goals and our user analysis, we did an Expert Walk-through through the VWCC. We captured key points of the existing CC, and inserted them as screenshots to pages in iRise. To identify them later on we used a significant name for each page and added page IDs. For pages captured from the existing CC we used “CC1.0 pagename”, for the new specification we used “CC2.x pagename”. The comment functions of iRise were used to document what we found to be good or bad about the VWCC (Figure 4). The criticised points were supplemented with several advices for improvements in CC2.X. The linking of the programme was used to produce a picture based, interactive map of the existing VWCC, in addition we could link the single pages of the simulation with our usability guidelines to reference them easily. This enabled us to show an offline picture based interactive presentation of his VWCC to our customer.

Figure 4: Using iRise to comment the current VWCC

2.2 Requirements Specification By evaluating the existing VWCC it was clear that we did not have to start from the begin-ning. Many things were positive and we could use them in the new version as well. We took the positive things and categorised them according to the categories of the usability goals (see 2.1.1 Usability Goals). Further we took the negative issues of the current CC and ex-pressed the suggestions of improvement as further goals.

In iRise we copied the existing scenario as basis for our new CC2.0. Static elements where built as reusable masters templates. Most of them were grabbed using normal screen capture


tools (Table 1: Used Tools). In iRise we had two possibilities to build a page. We could ei-ther simply use a screenshot of the page, which could only be done if we wanted to use the existing page one to one in our new CC, or we could rebuild the existing pages which means entering all the text, importing images etc. (Figure 5). iRise was unable to import the HTML pages of the existing VWCC, although its output is HTML formatted. An import function would have been of great help.

Using the design of the existing VWCC and further elements of the company's homepage we build every single page of the new CC2.0 following the usability guidelines we defined and eliminating the negative aspects of the existing VWCC.

With iRise it was easy to build a scenario by simply dragging pages into a new scenario and linking them together. Once a new page is created it is not possible to assign a master tem-plate to it, this is only possible by using the function “create from template”, which does not fit the process of building a simulation. The structure is designed first, then the pages are created. For designing graphical elements – even such basic elements like rectangles – we had to use common graphic editing tools, iRise could only be used to put all elements to-gether and link the pages.

Figure 5: Rebuilt version of the section “motor” (iRise)

2.3 Requirements Validation As previously mentioned we built a complete scenario of the new CC. During the regular meetings with the customer we could present the new CC having further online access to the


existing VWCC on a second PC. Therefore both versions of the CC could be presented in parallel and compared easily.

At the meetings we presented different ideas for the new and improved design. We were able to discuss the ideas by the browser-based iRise simulation. Comments and decisions from the customer were documented using the comment function of iRise. As an example the cus-tomer requested that the new CC should work without popups (Figure 6).

Figure 6: Designing the popup-free version of the radio-navigation page

2.4 Requirements Management Because of the highly iterative process it was necessary to react to changes very quickly. iRise supported us in doing this. We constructed new pages of the new CC whenever essen-tial changes had to be made. This was achieved by copying the page, adding a new ID and commenting the old and new versions with our decisions. This made both versions easy to distinguish.

For the next meeting we updated the simulation with our newly designed pages, once again giving the customer the opportunity to give feedback.


3 iRise Prototype In the previous chapters we pointed out our general strategy to develop a specification for a new VWCC, using an adapted requirements engineering process.

This chapter will present the result of this process, namely the visual specification itself, to-gether with its various alternatives and decisions that led to the final specification.

First we will present the defined usability goals that were the basics for all pages of the new VWCC. Then we will present the existing and the new VWCC side by side, showing all the new concepts we developed for the new version.

Finally we will rate the new CC according to our usability goals.

3.1 Usability Goals For The New VWCC During the walkthrough (see Chap. 2.1.3) we defined several usability issues; these were addressed in a set of usability goals.

1. Suitability for the task:

– The user is given meaningful aids to be able to select from. – Help, comparison and save functions are offered – The configured data is stored automatically and used in other applications, e.g. vehi-

cle search – The interface supports the defined user groups „novices“ and „experts“

2. Self-descriptiveness:

– Technical equipment such as ESP, ABS, etc. is described to the user. – Descriptions are reached within one mouse-click. Pictures, videos and simulations

supplement the descriptions. – An interior and exterior view is offered to the user. Configurations affect this view.

3. Controllability:

– The user is able to start the dialogue sequence, change its direction and speed. – A guided navigation process is offered - however it does not have to be used.

4. Conformity with user expectations:

– The user knows at each moment: – Where he is. His position in the configuration process. – Where he was. Which parts he has already configured. – Where he can go. Which parts he can still configure.

– The configuration process is logically designed for the user.


5. Error tolerance:

– The user receives a functional configuration at each time. – Configuration conflicts are avoided. If they appear they are described to the user.

6. Individualisation:

– The user can determine the size of the pictures or of the written information areas. – Switching between interior and external view is always possible.

7. Suitability for learning:

– The interface is designed in the look & feel of Volkswagen

3.2 Concepts To design the new VWCC we took the current CC as a style sheet together with the look and feel of the website. The basic concepts of the new VWCC will be presented in the subchap-ters following a chronological walkthrough of the new specification.

3.2.1 Welcome Page The welcome page of the current VWCC (Figure 7, left) shows the complete VW product family. It is good to have an overall view of all the available products, but presenting only the cars names is not of great help for all users. If one user would like to by a city-car and is not familiar with the names of the VW cars, he will have to look at every single car. The same is true for the price. If one user has a budget of e.g. 30.000€, he will have to find out which cars meet this criteria before he can begin his configuration.

This is why we added a small picture to each car in the new configurator and some initial price information. The user now has got the possibility to find the car meeting his needs al-ready in the overview.

The initial picture of the man in the upper area was turned around. Now it looks like he is reading the information available in the left side.


Figure 7: VWCC Welcome Page: Old version (left) and new version (right)

When the user moves the mouse over a specific car (rollover), a bigger image of it appears in the upper area of the configurator, together with general information about it (Figure 8). The information is presented as continuous text, which is not suitable for comparison or fast in-formation seeking. This is why we added a new scale to the car summary, where basic crite-ria are rated on a scale from one to five stars e.g. economy, size, etc. (Figure 8, right).

Figure 8: VWCC Welcome Page, Summery of VW Golf: Old version (left) and new version (right)

Integrating images and price information improved the self-descriptiveness of the items on the welcome page. The usage of space is improved, and the decision support aids that are offered to the user when selecting between alternatives are more meaningful.


Although there is more information visible to the user now, it is still hard to compare two or more models with each other; therefore we integrated a comparison tool.

3.2.2 Comparison To compare to or more cars with each other, they can be selected via checkboxes. As soon as more than one car is selected, the comparison button is activated. By pressing the compari-son button the comparison application will start. Cars can be compared by more features than in the preview, e.g. sportiness, comfort, disposable space, technical characteristics, etc. The user does not have to keep the characteristics in mind since they are all available on one screen (Figure 9).

The comparison tool is available during the whole configuration process. Depending at which step somebody is in the configuration process, one can compare cars, motors, or other features.

With the introduction of the comparison tool we improved the usability goal of suitability for the task.

Figure 9: VWCC: The New Comparison Tool, Golf vs. Golf Plus

3.2.3 Choice of type After selecting a certain model on the welcome page one is prompted to select a specific type. Every VW is available in different types; these types differ in price, motorisation, ex-tras and so on.


In the existing VWCC the different types are presented only by their names, on rollover the type is presented by a slightly different image and a description. Although not applicable and hence useless, the “next” button is present (Figure 10, left).

Figure 10: VWCC, Type Choice: Old version (left) and new version (right)

Anyway, the serious problem here is that a novice user does not know how to differentiate between the different car types. This information is missing or only present in later steps. Our proposal was to present the car variants in table form, together with useful information for decision making (Figure 10, right). If no alternative is chosen, the default option, basic model, is selected. The user now receives better support to decide.

3.2.4 Motor After choosing a car-type, the next step in the configuration process is the selection of a mo-tor. This is the initial step of the configuration process, which is readily identifiable by the grey menu separating the top image of the car with the configuration options at the bottom (Figure 11, left).

The user can either use the back and forward buttons to navigate through the configuration process or select one oft the four main categories. We kept this concept in the new VWCC, the feature we added was we coloured the category image green as soon as the user passed it (Figure 12, right). Now the user can easily recognise which steps of the configuration proc-ess are already done. We kept the controllability of the configuration process.

We considered the “motor” step of the old VWCC as reasonable. It already contains a lot of criteria for the user to select one specific engine.


Figure 11: VWCC, Motor: Old version (left) and new version (right)

We disliked the way the space in the lower area was used. Therefore we moved the informa-tion about elements already configured from the lower right to the upper right corner, next to the car that represents the configuration visually. This also led to more place for content in the lower area (Figure 11, right).

With respect to the details about motors we felt the need of more than textual descriptions. We introduced images, simulations and sounds so that the user can get a better feeling of the motor. They can be accessed directly from the table cell of each motor type.

We redesigned the detail information area similarly, in a table form, for all the other detail pages, the concept will be described later on.

3.2.5 Colour Combination The second step in the configuration process is choosing a colour for the outside and inside of the car (Figure 12, top-left).

The first positive thing to notice is that choices of colour combinations affect the images in the upper part of the screen.

The image size can be changed as well, which affects the space available for the configura-tion. When choosing the interior colours, the view changes automatically to an interior image of the car. These positive aspects were kept in our solution.

The negative part of this step is that there are incompatible colours that one can choose. Al-though the impossible combinations are shaded out, as if they could not be selected, they still can be. If it happens, then the user is prompted to deselect one of the not matching selections.


Furthermore, all interior equipment seem to be available at no additional cost, no price in-formation is given although e.g. the leather interior affords leather seats which cost nearly 2.000€. Choosing a leather interior brings up an error message telling the user to either select these leather seats or to delete the leather interior (Figure 12, bottom-left).

Figure 12: VWCC, Colour Combinations: Old version (left), new version (right), current error message (bottom)

We added price information to each option and bundled the leather interior with the leather seats (Figure 12, right). This eliminated the unnecessary error message indicating conflicts, leaving a functional configurator with no conflicts during the whole process.

Another goal achieved is individualisation. The user can modify the sizes of the areas of the configurator as he wishes and switch between interior and exterior views.


3.2.6 Special Equipment (Extras) This part of the VWCC was the one that needed most changes. All special equipment was available in one long list containing the name of the feature and the price together with a small icon for more information. For selection only checkboxes were used although in most cases radio buttons would have been appropriate, e.g. selecting tyres or radios (Figure 13, left).

Figure 13: VWCC, Extras: Old version (left) and new version (right)

What we did first was to group all the features into two categories, interior and exterior equipment. We decided to split the long list into categories, so that the screen was not over-filled. The categories were already available in the old VWCC and were used there to jump inside the long list. Again, visited categories are coloured green, to show the status of the configured parts. Further we highlighted important categories with a bold font to get the us-er’s attention (Figure 13, right).

As an example we designed the sections “radio and navigation” and “tyres”. In the radio and navigation section we introduced a similar table as on the “type choice” page. The columns of the table have meaningful attributes, which assist the user in choosing the radio or naviga-tion system he likes best. Like on most pages, the comparison function is available as well. The check boxes were replaced by radio buttons whenever there is only one alternative to choose.

We kept the little icon to get more information about one feature, but we changed the way this additional information is presented. In the old VWCC activating the icon brings up a small text and image about the feature. Activating the image brings up a bigger image in the upper part of the screen (Figure 14, left). The information about the feature is now split in two parts on the screen. The user has to switch back and forth between the two areas.


Figure 14: VWCC, Detail Information of Navigation System: Old version (left) and new version with two degrees of interest (right)

Our solution brings up the additional information in the same table cell underneath the fea-ture. We integrated bigger images from the start and added more multimedia content where suitable, e.g. videos, animations, interactive simulations etc. (Figure 14, top-right). The dif-ferent content is available through a small menu. The user can enlarge the multimedia con-tent by simply clicking on it. It will appear “full screen” in the configuration part of the screen (Figure 14, bottom-right).


The category radio and navigation can easily be represented in a table. With tyres we exem-plified a more visual category. The main characteristic of a tyre is its look and feel. This is why we represent tyres with images, which is more meaningful than any text (Figure 15).

Figure 15: VWCC, Detail Information of Tires: Old version (left) and new version (right)

3.2.7 Your Car Step four in the configuration process shows the user’s configured car. In the current VWCC, the user can bring up the description of the features (Figure 16, left). As the user might want to edit or delete parts of his configuration we added these options to every configured feature (Figure 16, right). Pressing the delete link will delete the option. Pressing the edit link will bring the user to the appropriate step of the configuration process.

Small preview images were added to the configured features to assist novice users that might not know the name of the feature.


Figure 16: VWCC, Your Car (Presentation of Configured Car): Old version (left) and new version (right)


3.3 Benchmark of the new VWCC In chapter 3.2 we presented the core concepts of the new VWCC and in some parts described how our changes lead to a better and more usable version of the VWCC. In this chapter we will rate the new VWCC according to our previously defined usability guidelines and match the guidelines with out optimisations.

We used one star for all usability goals which were reached just as good as the old VWCC simply because there was no matter to change anything. Two stars mean that our solution is better than the old VWCC since we changed small things. Three stars we used for our high-lights, where we felt our new VWCC outperforms the old one.

Rating Guideline Rationale Suitability for the task:

The user is given meaningful aids to be able to select from.

New table layout helps users to select fea-tures appropriately. Adding further information to product names (e.g. tyres or welcome page) gives useful hints to make a selection.

Help, comparison and save functions are offered

New comparison tool introduced.

The configured data is stored automatically and used in other applications e.g. vehicle search

As in old VWCC

The interface supports the defined user groups „novices“ and „experts“

Old VWCC was good for experts. More images and other multimedia elements help novice users.

Self-descriptiveness:

Technical equipment such as ESP, ABS, etc is described to the user.

Information pages now contain more de-scriptions. Visual descriptions added.

Descriptions ale reached within one mouse-click. Pictures, videos and simulations sup-plement the descriptions.

True for basic information. Here one mouse click is needed. For “full screen” images, demos etc. two mouse clicks are needed.

An interior and exterior view is offered to the user. Configurations affect this view.

This was already good in the old VWCC. We also change the view according to what the user is configuring.


Rating Guideline Rationale

Controllability:

The user is able to start the dialogue se-quence, change its direction and speed.

As in old VWCC.

A guided navigation process is offered - however it does not have to be used.

As in old VWCC.

Conformity with user expectations:

The user knows at each moment:

• Where he is. His position in the configuration process.

• Where he was. Which parts he has already configured.

• Where he can go. Which parts he can still configure.

Marking the already visited steps green visualizes the status of the configuration. The user now knows where he has already been in the configuration process.

The configuration process is logically de-signed for the user.

As in old VWCC.

Error tolerance:

The user receives a functional configuration all the time.

Preconfiguring a default configuration keeps the configuration functional all the time.

Configuration conflicts are avoided. If they appear they are described to the user.

Bundled features are only available as bun-dles, this avoids most of the conflicts.

Individualisation:

The user can determine the size of the pic-tures or of the written information areas.

As in old VWCC.

Switching between interior and external view is always possible.

As in old VWCC.

Suitability for learning:

The interface is designed in the look & feel of Volkswagen

As in old VWCC.


4 Summary And Outlook The features of simulation tools are necessary to visualize projects with user experience much earlier within the development lifecycle. They can be dedicated to bridging the gap between the stakeholders by improving the process of defining business applications.

In this project we tried to find out the main advantages of visual requirements engineering. We further wanted to evaluate if iRise is an appropriate tool for defining a visual specifica-tion. During the requirements engineering process, using the simulations of iRise was of great help to communicate our ideas and concepts to the customer. The customer could not only see the product in form of screenshots, but interact with it, too. Depending on how well iRise pages were built, making changes was very easy, thus several different design alterna-tives could be evaluated together with the customer. The result was a visual specification that outperformed the current VWCC in terms of usability.

Although we were not able to test all features of iRise, like the database simulation, we found out that there are still many things that can be optimised, e.g. import functions, col-laboration and editing capabilities.

The interactivity and ease-of-use in conjunction with portability and reusability of the simu-lations could be the key facts by choosing the right simulation software. We are curious to watch how each of these simulation packages will be improved over the next years with new features or better integration to third-party products.


5 References iRi07: iRise, Company Overview, 17.02.2007, http://irise.com/company/index.php (visited 17.02.2007)

Vol06: Volere template, 10.12.2006, http://www.volere.co.uk (visited 10.12.2006)

USE07: USERFOCUS, ISO 9241 Part 110, 02.01.2007, http://www.userfocus.co.uk/resources/iso9241/part110.html (visited 02.01.2007)

6 Appendix

Appendix A – used Tools

Task Tool(s)

Specification iRise Studie_v5.3

Graphics Adobe Photoshop CS1 Microsoft Office Picture Manager

Data exchange BSCW_v4.3.3

Communication E-Mail Skype_v3.0.0.209 (VoIP, IM)

Time and division of work managing Microsoft Excel 2003

Screen-Capture FastStone Capture_v4.8 PrintScreen key and Paint

Demonstration and presentation Mozilla Firefox_v2.0.0.1 Microsoft Internet Explorer_v6.0.29 and 7.0

Table 1: Used Tools


Appendix B – Field Report The experience we had with iRise had positive and negative aspects. iRise is very good in rapidly and simply building different scenarios. Linking is extremely easy also between pro-jects, making it possible to integrate pages from multiple projects. But these links get lost in case of page integration or if the document is exported into the iDoc format.

The content cannot be directly imported; it has to be brought in step-by-step, component-by-component. Available HTML pages must be rebuilt laboriously, because there is no import function. During this work it was extremely inconvenient not to be able to open more docu-ments simultaneously, but at least it was possible to copy content from one to another.

It’s relatively easy to organize the content (text, images, etc.). However, it can require some effort to format text. Simple enumerations are not available and there are problems regarding German and other special characters. It isn’t possible to set a link to only one word; this has to be set on the whole phrase. The program has no possibility to work on pictures or create simple forms.

The navigation list is not arranged clearly. The contained elements can’t be sorted or ver-sioned automatically. The not existing “save”-function is confusing. Only “save as” is sup-ported. After a while, the user discovers that iRise saves the projects automatically, but he has no idea when and how or whether it is necessary to “save” the document before closing it or not.

To work with iRise Studio is sometimes hard, because it’s slow and therefore time intensive. But the compiled results are good. The export function to MS Word delivers a pixels exact specification of the product.

Appendix C – iDoc from the existing to the new CC See files VWCC-Evolution.idoc and VWCC-Presentation.idoc.

For an MS Word export see VWCC-Presentation.doc

Volkswagen Car Configurator

Documents