InfoVis:Wiki - User contributions [en]

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-22T18:28:55Z

UE-InfoVis0506 0325693: /* User */

==Topic==
On-line Music Portals: Analyzing the Users' Activities

==Area of Application==
This section describes the application area of 
'''MICE - Music Investigation and Clustering Environment'''.

[[Image:MICELogo.gif]] [Stefan Schnabl, 2005]

===Analysis of Application Area===

====General Description====
The dataset contains data of a special online music portal. 
http://www.ericsson-mediasuite.com/music/web2/dyn/home

The great aim is to get information out about the activity of the users in the special areas. Maybe this can open up some hypothesis how the portal can be optimzies or restructured. 
If a siginificant correlation between certain aspects can be found, this could be interesting for the portal owners and the technicians how established the portal.

====Special Issues====
We identified the following spots of interest:
# The user of MICE has different intentions than the person the data is about
# Basket Case Analysis and Cluster Analysis are heavily statistical techniques and quite intense in terms of required knowledge
# The questions wanted to be solved will gain on complexity once they are answered (report chain)
# The answering will not be a single "result" but a (iterative) process.
# Heavy task to realize an abstract graphical view on the data.

===Analysis of the Dataset===
The data is organized in several tables which refer to each other by Item Ids. The following tables are available:
{|
|width="130"| - Album||Represents all albums available.
|-
| - Artist||Contains information about the known artists.
|-
| - Track||References between ''Album'' and ''Artist''.
|-
| - Asset||Information concerning the products which are sold.
|-
| - Playlist||Contains information about the playlists created by the users of the on-line portal.
|-
| - Playlist Item ||Associative reference between ''Track'' and ''Playlist''.
|-
| - User||Information concerning the users of the on-line portal. Referenced to ''Playlist''.
|-
| - User action||Data containing information about the operation a user executes within the on-line portal. Referenced to ''User'' and ''Track'', ''Asset'', or ''Artist''.
|}
The user behaviour results in the tables ''User'' and ''User action''. All the other information is brought in by companies distributing such content.
====Description of the Datatypes====
The tables consist of the following Data items:
=====Album=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|artistId||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|homeClusters||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|creationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|albumId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|not NULL
|-
|title||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|albumId||bgcolor="#eeeeee"|Primary Key||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Artist=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|creationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|defaultAssetId||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|firstName||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|artistId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|not NULL
|-
|lastName||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|homeClusters||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|artistId||Primary Key|| ||
|}
=====Track=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|artistId||Integer (20 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|creationDate||bgcolor="#eeeeee"|DateTime [key]||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|trackId||Integer (20 Bytes) [key]||0||not NULL
|-
|bgcolor="#eeeeee"|title||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|ISRC||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|homeCluster||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|albumId||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|trackId||bgcolor="#eeeeee"|Primary Key ||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Asset=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|artistId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|assetType||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|creationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|assetId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|not NULL
|-
|trackId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|assetId||bgcolor="#eeeeee"|Primary Key ||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Playlist=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|claim||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|creationDate||bgcolor="#eeeeee"|DateTime||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|playlistId||Integer (20 Bytes)||0||not NULL
|-
|bgcolor="#eeeeee"|playListName||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|userId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|playlistId||bgcolor="#eeeeee"|Primary Key||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Playlist Item=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|trackId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|playlistId||bgcolor="#eeeeee"|Integer (20 Bytes) [key]||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|}
=====User=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|handSetId||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|userId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|NOT NULL, auto increment
|-
|language||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|lastLoginDate||bgcolor="#eeeeee"|DateTime||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|registrationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|gender||bgcolor="#eeeeee"|Character||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|yearOfBirth||unsigned Integer (10 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|genrePref||bgcolor="#eeeeee"|String(250 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|favouredArtists||String (no size specified)||
|-
|bgcolor="#eeeeee"|userId||bgcolor="#eeeeee"|Primary Key||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}

=====User Action=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|context||Integer (11 Bytes)||-1||NOT NULL
|-
|bgcolor="#eeeeee"|userId||bgcolor="#eeeeee"|Integer (20 Bytes) [key]||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|NOT NULL
|-
|productId||Integer (20 Bytes) [key]||0||NOT NULL
|-
|bgcolor="#eeeeee"|actionTime||bgcolor="#eeeeee"|TimeStamp [key]||bgcolor="#eeeeee"|0000-00-00 00:00:00||bgcolor="#eeeeee"|NOT NULL
|-
|action||String (20 Bytes)||<emtpy>||NOT NULL
|-
|bgcolor="#eeeeee"|productType||bgcolor="#eeeeee"|String (20 Bytes)||bgcolor="#eeeeee"|<emtpy>||bgcolor="#eeeeee"|NOT NULL
|}

====Description of the Datastructures====
The tables are in touch with each other in the following way: The ''artist'' entity can be considered as the central point of the structure. It may be referenced to none or more assets, one or more ''album'', one or more ''tracks'' and none or several ''user actions''. ''Tracks'' and ''assets'' can also be referenced to several ''user actions''. Due to the circumstance that a ''user action'' is always being executed by a user, there has to be a ''user'' - entitiy which can be referenced to several ''user actions''. Further, ''playlists'' can be created by a ''user'' which results in a 1:n reference between ''user'' and the ''playlist''-entity. The reference between the playlist and the contained tracks which is used to be a m:n reference is split up by the ''playlist item''-entity.
Finally ''tracks'' can be referenced to one or more ''clusters'' and a ''cluster'' may be in relation to 'super clusters', which are also contained in the ''cluster'' entity.

[[Image:MiceERD.png]]

The symbols have to be interpreted in the following way: [[Image:MiceRelation.png]] represents a 1:n reference between the entities A and B. One item of the entity B is referred to several items of the entity A. Further the minimum numbers of references may be specified with a small circle or a short line which can be interpreted as 0 or 1. So a circle (0) means that the reference pointer may be set to NULL, whereas a short line (1) means that there has to be at least one reference.

==Target Group==

===Identifying the Target===
The target for the exploration tool are mainly '''shopping analysts''' and '''web developer'''. 
It is the aim to suit the needs of persone who run the on-line portal (since they are interested in optimization). On the other hand one must not forget about the technical aspects, and by that help the developers of such systems.

===Special Issues of the Target Group===
# Shop Owners: Extremely '''business focused'''.
# Web Developers: Extremely '''technically focused'''.
# Maybe forgetting the users needs to "feel good".

===Known Solutions / Methods (related to the target group)===
# Data Mining
# SASS Enterprise Miner
# SPSS Statistical Investigation Tool
# => All very heavily statistically oriented.

==Intended Purpose==

===Goals and Objectives===

===Problems and Tasks to Solve===
# Giving a good overview without cutting away to much paths to the depth of the data.
# Clear mapping of variables.
# Clarify wht the user can expect by using certain buttons and methods.
# Cear structure of the methods.
# Consistency in usage of buttons and colors.
# Good guidance about wht to do with the results of a step of a method.
# Keep focused on matra: Overview First - Zoom and Focus - Details on Demand!

===Example Questions===
# In which timespan was a lot of activity?
# What are '''the buyers''' doing before or after they bought?
# How many people are visiting the different parts of the portal?
# Is VIEW and BUY correlated?
# Are there '''impulse buyers'''?

==Proposed Design==

===Types of Visualization Applied===
# '''Bubble Chart:''' Representing the parts of the online platform through bubbles. The traffic (or actions of people equal in the bubbles) is represented by the edges between the bubbles. Moreover the color inside the bubbles gives the proportions of persons as part of a selected group. A part stays grey representing "the rest".
# '''Parallel Coordinates:''' The Variables selected are normalized (to a range of 0-1) and plotted into a parallel coordinate plot. Techniques as Focus/Context must be appield to be able to figure out patterns.
# '''(multidimensional) Scatterplot:''' A Scatterplot helping to understand (maybe in more detail) the relations of some variables.
# '''Morphing (timeline):''' The datasets are timestamped and thus can ve used to make a morphing of the plots. By that it is possible to see whether there are special occurences (maybe heavy advertisement leads to more activity).

===Visual Mapping===
The basic data represented are '''user actions'''. The essential table should be enhanced with a column indicating the user as an '''profiled''' user (or not).

====Bubble Chart====
# The size of the bubble represents the number of actions taken within the part of the portal. Since the portal is semantically divided in parts in which you just can set actions on disjunct products, the different product types are also represented through this basic view.
# Different color segments of the bubble represent the (selected) type of actions.
# The position on the timeline represents all the actions taken until a special point of time. Moreover this can be regulated to show all actions in a special timespan.
# The "whole" is always visible through a very transparent bubblechart giving the idea of all the actions.
# The details to the segments and bubbles are becoming visible as Tiptext via the mousepointer when rolling over the segment or bubble.

====Parallel Coordinates====

The following attributes should be a fix part of the chart:
# Product Type
# User Action
# maybe: Time from 0-24

The following attributes can be additionally added to the chart:
# Cluster
# Age of User
# Asset Type
# ...

Very important is that some attributes exclude themselves (like assets and tracks are disjunct groups). This is not a ''structure'' but defined.

It must be possible to add color for certain constraints to the data:
# The profiled and unprofiled user
# the timespan of the actions
# ...

Additionally:
# Brushing
# Linking

====(multidimensional) Scatterplot====
# All Varaibles can be assigned to an axis.
# There is a maximum of 3 variables at the same time.
# There can be used a set of varaibles which is then exchanged continously using a subset of 3 variables out of the selected ones at a time.
# There can be color added to the plot giving additional information (see Parallel Coordinates).

====Morphing====
# Specify start and end point.
# Hit play to let morphing happen within the assigned timespan.
# Hit STOP to set the header to the starting time.
# Hit PAUSE to stop the header at any time.
# Drag and Drop the head to jump to a specific time.
# Switch between an absolute and relative time-axis.

===Description of Used Techniques===
(see above)

===Possibilities of Interaction===
# In any stage of the charts one can make use of the '''timeline''' to focus.
# Hook on on/off checkboxes at the left to include/exclude certain user actions.
# Assign color to charts to represent special groups (e.g. profiled and unprofiled user)
# Assign different symbols (where possible) instead of colors.
# Rotation of subsamples of variables when selecting more than 3 (Scatterplot).
# Zoom to special Bubble down to the one user action.
# Providing user data for the one user on demand and showing data in detail section.

===Mockups / Fake Screenshots===
[[image:Screenshot2_structure.jpg]]
 
 
[[image:Screenshot2_small.jpg]]

----
< [[Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8|G8]] 
<< [[Teaching:TUW_-_UE_InfoVis_WS_2005/06|overview]]

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-22T18:04:11Z

UE-InfoVis0506 0325693: /* Description of the Datastructures */

==Topic==
On-line Music Portals: Analyzing the Users' Activities

==Area of Application==
This section describes the application area of 
'''MICE - Music Investigation and Clustering Environment'''.

[[Image:MICELogo.gif]] [Stefan Schnabl, 2005]

===Analysis of Application Area===

====General Description====
Shopping analysis, Cluster / Pattern analysis, Web based area of application, all data analysed comes form online users, areas of application include shopping optimazation, web application development, technical optimization. The tool might also be interesting for pure online stores.

====Special Issues====
We identified the following spots of interest:
# The user of MICE has different intentions than the person the data is about
# Basket Case Analysis and Cluster Analysis are heavily statistical techniques and quite intense in terms of required knowledge
# The questions wanted to be solved will gain on complexity once they are answered (report chain)
# The answering will not be a single "result" but a (iterative) process.
# Heavy task to realize an abstract graphical view on the data.
# ...

===Analysis of the Dataset===
The data is organized in several tables which refer to each other by Item Ids. The following tables are available:
{|
|width="130"| - Album||Represents all albums available.
|-
| - Artist||Contains information about the known artists.
|-
| - Track||References between ''Album'' and ''Artist''.
|-
| - Asset||Information concerning the products which are sold.
|-
| - Playlist||Contains information about the playlists created by the users of the on-line portal.
|-
| - Playlist Item ||Associative reference between ''Track'' and ''Playlist''.
|-
| - User||Information concerning the users of the on-line portal. Referenced to ''Playlist''.
|-
| - User action||Data containing information about the operation a user executes within the on-line portal. Referenced to ''User'' and ''Track'', ''Asset'', or ''Artist''.
|}
The user behaviour results in the tables ''User'' and ''User action''. All the other information is brought in by companies distributing such content.
====Description of the Datatypes====
The tables consist of the following Data items:
=====Album=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|artistId||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|homeClusters||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|creationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|albumId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|not NULL
|-
|title||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|albumId||bgcolor="#eeeeee"|Primary Key||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Artist=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|creationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|defaultAssetId||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|firstName||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|artistId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|not NULL
|-
|lastName||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|homeClusters||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|artistId||Primary Key|| ||
|}
=====Track=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|artistId||Integer (20 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|creationDate||bgcolor="#eeeeee"|DateTime [key]||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|trackId||Integer (20 Bytes) [key]||0||not NULL
|-
|bgcolor="#eeeeee"|title||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|ISRC||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|homeCluster||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|albumId||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|trackId||bgcolor="#eeeeee"|Primary Key ||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Asset=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|artistId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|assetType||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|creationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|assetId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|not NULL
|-
|trackId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|assetId||bgcolor="#eeeeee"|Primary Key ||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Playlist=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|claim||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|creationDate||bgcolor="#eeeeee"|DateTime||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|playlistId||Integer (20 Bytes)||0||not NULL
|-
|bgcolor="#eeeeee"|playListName||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|userId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|playlistId||bgcolor="#eeeeee"|Primary Key||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Playlist Item=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|trackId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|playlistId||bgcolor="#eeeeee"|Integer (20 Bytes) [key]||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|}
=====User=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|handSetId||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|userId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|NOT NULL, auto increment
|-
|language||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|lastLoginDate||bgcolor="#eeeeee"|DateTime||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|registrationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|gender||bgcolor="#eeeeee"|Character||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|yearOfBirth||unsigned Integer (10 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|genrePref||bgcolor="#eeeeee"|String(250 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|favouredArtists||String||
|-
|bgcolor="#eeeeee"|userId||bgcolor="#eeeeee"|Primary Key||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}

=====User Action=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|context||Integer (11 Bytes)||-1||NOT NULL
|-
|bgcolor="#eeeeee"|userId||bgcolor="#eeeeee"|Integer (20 Bytes) [key]||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|NOT NULL
|-
|productId||Integer (20 Bytes) [key]||0||NOT NULL
|-
|bgcolor="#eeeeee"|actionTime||bgcolor="#eeeeee"|TimeStamp [key]||bgcolor="#eeeeee"|0000-00-00 00:00:00||bgcolor="#eeeeee"|NOT NULL
|-
|action||String (20 Bytes)||<emtpy>||NOT NULL
|-
|bgcolor="#eeeeee"|productType||bgcolor="#eeeeee"|String (20 Bytes)||bgcolor="#eeeeee"|<emtpy>||bgcolor="#eeeeee"|NOT NULL
|}

====Description of the Datastructures====
The tables are in touch with each other in the following way: The ''artist'' entity can be considered as the central point of the structure. It may be referenced to none or more assets, one or more ''album'', one or more ''tracks'' and none or several ''user actions''. ''Tracks'' and ''assets'' can also be referenced to several ''user actions''. Due to the circumstance that a ''user action'' is always being executed by a user, there has to be a ''user'' - entitiy which can be referenced to several ''user actions''. Further, ''playlists'' can be created by a ''user'' which results in a 1:n reference between ''user'' and the ''playlist''-entity. The reference between the playlist and the contained tracks which is used to be a m:n reference is split up by the ''playlist item''-entity.
Finally ''tracks'' can be referenced to one or more ''clusters'' and a ''cluster'' may be in relation to 'super clusters', which are also contained in the ''cluster'' entity.

[[Image:MiceERD.png]]

The symbols have to be interpreted in the following way: [[Image:MiceRelation.png]] represents a 1:n reference between the entities A and B. One item of the entity B is referred to several items of the entity A. Further the minimum numbers of references may be specified with a small circle or a short line which can be interpreted as 0 or 1. So a circle (0) means that the reference pointer may be set to NULL, whereas a short line (1) means that there has to be at least one reference.

==Target Group==

===Identifying the Target===
The target for the exploration tool are mainly '''shopping analysts''' and '''web developer'''. 
It is the aim to suit the needs of persone who run the on-line portal (since they are interested in optimization). On the other hand one must not forget about the technical aspects, and by that help the developers of such systems.

===Special Issues of the Target Group===
# Shop Owners: Extremely '''business focused'''.
# Web Developers: Extremely '''technically focused'''.
# Maybe forgetting the users needs to "feel good".

===Known Solutions / Methods (related to the target group)===
# Data Mining
# SASS Enterprise Miner
# SPSS Statistical Investigation Tool
# => All very heavily statistically oriented.

==Intended Purpose==

===Goals and Objectives===

===Problems and Tasks to Solve===
# Giving a good overview without cutting away to much paths to the depth of the data.
# Clear mapping of variables.
# Clarify wht the user can expect by using certain buttons and methods.
# Cear structure of the methods.
# Consistency in usage of buttons and colors.
# Good guidance about wht to do with the results of a step of a method.
# Keep focused on matra: Overview First - Zoom and Focus - Details on Demand!

===Example Questions===
# In which timespan was a lot of activity?
# What are '''the buyers''' doing before or after they bought?
# How many people are visiting the different parts of the portal?
# Is VIEW and BUY correlated?
# Are there '''impulse buyers'''?

==Proposed Design==

===Types of Visualization Applied===
# '''Bubble Chart:''' Representing the parts of the online platform through bubbles. The traffic (or actions of people equal in the bubbles) is represented by the edges between the bubbles. Moreover the color inside the bubbles gives the proportions of persons as part of a selected group. A part stays grey representing "the rest".
# '''Parallel Coordinates:''' The Variables selected are normalized (to a range of 0-1) and plotted into a parallel coordinate plot. Techniques as Focus/Context must be appield to be able to figure out patterns.
# '''(multidimensional) Scatterplot:''' A Scatterplot helping to understand (maybe in more detail) the relations of some variables.
# '''Morphing (timeline):''' The datasets are timestamped and thus can ve used to make a morphing of the plots. By that it is possible to see whether there are special occurences (maybe heavy advertisement leads to more activity).

===Visual Mapping===
The basic data represented are '''user actions'''. The essential table should be enhanced with a column indicating the user as an '''profiled''' user (or not).

====Bubble Chart====
# The size of the bubble represents the number of actions taken within the part of the portal. Since the portal is semantically divided in parts in which you just can set actions on disjunct products, the different product types are also represented through this basic view.
# Different color segments of the bubble represent the (selected) type of actions.
# The position on the timeline represents all the actions taken until a special point of time. Moreover this can be regulated to show all actions in a special timespan.
# The "whole" is always visible through a very transparent bubblechart giving the idea of all the actions.
# The details to the segments and bubbles are becoming visible as Tiptext via the mousepointer when rolling over the segment or bubble.

====Parallel Coordinates====

The following attributes should be a fix part of the chart:
# Product Type
# User Action
# maybe: Time from 0-24

The following attributes can be additionally added to the chart:
# Cluster
# Age of User
# Asset Type
# ...

Very important is that some attributes exclude themselves (like assets and tracks are disjunct groups). This is not a ''structure'' but defined.

It must be possible to add color for certain constraints to the data:
# The profiled and unprofiled user
# the timespan of the actions
# ...

Additionally:
# Brushing
# Linking

====(multidimensional) Scatterplot====
# All Varaibles can be assigned to an axis.
# There is a maximum of 3 variables at the same time.
# There can be used a set of varaibles which is then exchanged continously using a subset of 3 variables out of the selected ones at a time.
# There can be color added to the plot giving additional information (see Parallel Coordinates).

====Morphing====
# Specify start and end point.
# Hit play to let morphing happen within the assigned timespan.
# Hit STOP to set the header to the starting time.
# Hit PAUSE to stop the header at any time.
# Drag and Drop the head to jump to a specific time.
# Switch between an absolute and relative time-axis.

===Description of Used Techniques===
(see above)

===Possibilities of Interaction===
# In any stage of the charts one can make use of the '''timeline''' to focus.
# Hook on on/off checkboxes at the left to include/exclude certain user actions.
# Assign color to charts to represent special groups (e.g. profiled and unprofiled user)
# Assign different symbols (where possible) instead of colors.
# Rotation of subsamples of variables when selecting more than 3 (Scatterplot).
# Zoom to special Bubble down to the one user action.
# Providing user data for the one user on demand and showing data in detail section.

===Mockups / Fake Screenshots===
[[image:Screenshot2_structure.jpg]]
 
 
[[image:Screenshot2_small.jpg]]

----
< [[Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8|G8]] 
<< [[Teaching:TUW_-_UE_InfoVis_WS_2005/06|overview]]

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-22T18:00:27Z

UE-InfoVis0506 0325693: /* Description of the Datastructures */

==Topic==
On-line Music Portals: Analyzing the Users' Activities

==Area of Application==
This section describes the application area of 
'''MICE - Music Investigation and Clustering Environment'''.

[[Image:MICELogo.gif]] [Stefan Schnabl, 2005]

===Analysis of Application Area===

====General Description====
Shopping analysis, Cluster / Pattern analysis, Web based area of application, all data analysed comes form online users, areas of application include shopping optimazation, web application development, technical optimization. The tool might also be interesting for pure online stores.

====Special Issues====
We identified the following spots of interest:
# The user of MICE has different intentions than the person the data is about
# Basket Case Analysis and Cluster Analysis are heavily statistical techniques and quite intense in terms of required knowledge
# The questions wanted to be solved will gain on complexity once they are answered (report chain)
# The answering will not be a single "result" but a (iterative) process.
# Heavy task to realize an abstract graphical view on the data.
# ...

===Analysis of the Dataset===
The data is organized in several tables which refer to each other by Item Ids. The following tables are available:
{|
|width="130"| - Album||Represents all albums available.
|-
| - Artist||Contains information about the known artists.
|-
| - Track||References between ''Album'' and ''Artist''.
|-
| - Asset||Information concerning the products which are sold.
|-
| - Playlist||Contains information about the playlists created by the users of the on-line portal.
|-
| - Playlist Item ||Associative reference between ''Track'' and ''Playlist''.
|-
| - User||Information concerning the users of the on-line portal. Referenced to ''Playlist''.
|-
| - User action||Data containing information about the operation a user executes within the on-line portal. Referenced to ''User'' and ''Track'', ''Asset'', or ''Artist''.
|}
The user behaviour results in the tables ''User'' and ''User action''. All the other information is brought in by companies distributing such content.
====Description of the Datatypes====
The tables consist of the following Data items:
=====Album=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|artistId||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|homeClusters||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|creationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|albumId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|not NULL
|-
|title||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|albumId||bgcolor="#eeeeee"|Primary Key||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Artist=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|creationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|defaultAssetId||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|firstName||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|artistId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|not NULL
|-
|lastName||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|homeClusters||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|artistId||Primary Key|| ||
|}
=====Track=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|artistId||Integer (20 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|creationDate||bgcolor="#eeeeee"|DateTime [key]||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|trackId||Integer (20 Bytes) [key]||0||not NULL
|-
|bgcolor="#eeeeee"|title||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|ISRC||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|homeCluster||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|albumId||String (255 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|trackId||bgcolor="#eeeeee"|Primary Key ||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Asset=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|artistId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|assetType||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|creationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|assetId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|not NULL
|-
|trackId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|assetId||bgcolor="#eeeeee"|Primary Key ||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Playlist=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|claim||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|creationDate||bgcolor="#eeeeee"|DateTime||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|playlistId||Integer (20 Bytes)||0||not NULL
|-
|bgcolor="#eeeeee"|playListName||bgcolor="#eeeeee"|String (255 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|userId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|playlistId||bgcolor="#eeeeee"|Primary Key||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}
=====Playlist Item=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|trackId||Integer (20 Bytes) [key]||NULL||
|-
|bgcolor="#eeeeee"|playlistId||bgcolor="#eeeeee"|Integer (20 Bytes) [key]||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|}
=====User=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|handSetId||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|userId||bgcolor="#eeeeee"|Integer (20 Bytes)||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|NOT NULL, auto increment
|-
|language||String (255 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|lastLoginDate||bgcolor="#eeeeee"|DateTime||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|registrationDate||DateTime||NULL||
|-
|bgcolor="#eeeeee"|gender||bgcolor="#eeeeee"|Character||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|yearOfBirth||unsigned Integer (10 Bytes)||NULL||
|-
|bgcolor="#eeeeee"|genrePref||bgcolor="#eeeeee"|String(250 Bytes)||bgcolor="#eeeeee"|NULL||bgcolor="#eeeeee"|
|-
|favouredArtists||String||
|-
|bgcolor="#eeeeee"|userId||bgcolor="#eeeeee"|Primary Key||bgcolor="#eeeeee"| ||bgcolor="#eeeeee"|
|}

=====User Action=====
{|
|bgcolor="#e0e0e0" width="130"|'''Field Name'''||width="130" bgcolor="#e0e0e0"|'''Datatype'''||width="130" bgcolor="#e0e0e0"|'''Default value'''||width="130" bgcolor="#e0e0e0"|'''Constraints'''
|-
|context||Integer (11 Bytes)||-1||NOT NULL
|-
|bgcolor="#eeeeee"|userId||bgcolor="#eeeeee"|Integer (20 Bytes) [key]||bgcolor="#eeeeee"|0||bgcolor="#eeeeee"|NOT NULL
|-
|productId||Integer (20 Bytes) [key]||0||NOT NULL
|-
|bgcolor="#eeeeee"|actionTime||bgcolor="#eeeeee"|TimeStamp [key]||bgcolor="#eeeeee"|0000-00-00 00:00:00||bgcolor="#eeeeee"|NOT NULL
|-
|action||String (20 Bytes)||<emtpy>||NOT NULL
|-
|bgcolor="#eeeeee"|productType||bgcolor="#eeeeee"|String (20 Bytes)||bgcolor="#eeeeee"|<emtpy>||bgcolor="#eeeeee"|NOT NULL
|}

====Description of the Datastructures====
The tables are in touch with each other in the following way: The ''artist'' entity can be considered as the central point of the structure. It may be referenced to none or more assets, one or more ''album'', one or more ''tracks'' and none or several ''user actions''. ''Tracks'' and ''assets'' can also be referenced to several ''user actions''. Due to the circumstance that a ''user action'' is always being executed by a user, there has to be a ''user'' - entitiy which can be referenced to several ''user actions''. Further, ''playlists'' can be created by a ''user'' which results in a 1:n reference between ''user'' and the ''playlist''-entity. The reference between the playlist and the contained tracks which is used to be a m:n reference is split up by the ''playlist item''-entity.
Finally ''tracks'' can be referenced to one or more ''clusters'' and a ''cluster'' may be in relation to 'super clusters', which are also contained in the ''cluster'' entity.

[[Image:MiceERD.png]]

The symbols have to be interpreted in the following way: [[Image:MiceRelation.png]] represents a 1:n reference between the entities A and B. One item of the entity B is referred to several items of the entity A. Further the minimum numbers of references may be specified with a small circle or a short line which can be interpreted as 0 or 1. So a circle means that the reference pointer may be set to NULL, whereas a line means that there has to be at least one reference.

==Target Group==

===Identifying the Target===
The target for the exploration tool are mainly '''shopping analysts''' and '''web developer'''. 
It is the aim to suit the needs of persone who run the on-line portal (since they are interested in optimization). On the other hand one must not forget about the technical aspects, and by that help the developers of such systems.

===Special Issues of the Target Group===
# Shop Owners: Extremely '''business focused'''.
# Web Developers: Extremely '''technically focused'''.
# Maybe forgetting the users needs to "feel good".

===Known Solutions / Methods (related to the target group)===
# Data Mining
# SASS Enterprise Miner
# SPSS Statistical Investigation Tool
# => All very heavily statistically oriented.

==Intended Purpose==

===Goals and Objectives===

===Problems and Tasks to Solve===
# Giving a good overview without cutting away to much paths to the depth of the data.
# Clear mapping of variables.
# Clarify wht the user can expect by using certain buttons and methods.
# Cear structure of the methods.
# Consistency in usage of buttons and colors.
# Good guidance about wht to do with the results of a step of a method.
# Keep focused on matra: Overview First - Zoom and Focus - Details on Demand!

===Example Questions===
# In which timespan was a lot of activity?
# What are '''the buyers''' doing before or after they bought?
# How many people are visiting the different parts of the portal?
# Is VIEW and BUY correlated?
# Are there '''impulse buyers'''?

==Proposed Design==

===Types of Visualization Applied===
# '''Bubble Chart:''' Representing the parts of the online platform through bubbles. The traffic (or actions of people equal in the bubbles) is represented by the edges between the bubbles. Moreover the color inside the bubbles gives the proportions of persons as part of a selected group. A part stays grey representing "the rest".
# '''Parallel Coordinates:''' The Variables selected are normalized (to a range of 0-1) and plotted into a parallel coordinate plot. Techniques as Focus/Context must be appield to be able to figure out patterns.
# '''(multidimensional) Scatterplot:''' A Scatterplot helping to understand (maybe in more detail) the relations of some variables.
# '''Morphing (timeline):''' The datasets are timestamped and thus can ve used to make a morphing of the plots. By that it is possible to see whether there are special occurences (maybe heavy advertisement leads to more activity).

===Visual Mapping===
The basic data represented are '''user actions'''. The essential table should be enhanced with a column indicating the user as an '''profiled''' user (or not).

====Bubble Chart====
# The size of the bubble represents the number of actions taken within the part of the portal. Since the portal is semantically divided in parts in which you just can set actions on disjunct products, the different product types are also represented through this basic view.
# Different color segments of the bubble represent the (selected) type of actions.
# The position on the timeline represents all the actions taken until a special point of time. Moreover this can be regulated to show all actions in a special timespan.
# The "whole" is always visible through a very transparent bubblechart giving the idea of all the actions.
# The details to the segments and bubbles are becoming visible as Tiptext via the mousepointer when rolling over the segment or bubble.

====Parallel Coordinates====

The following attributes should be a fix part of the chart:
# Product Type
# User Action
# maybe: Time from 0-24

The following attributes can be additionally added to the chart:
# Cluster
# Age of User
# Asset Type
# ...

Very important is that some attributes exclude themselves (like assets and tracks are disjunct groups). This is not a ''structure'' but defined.

It must be possible to add color for certain constraints to the data:
# The profiled and unprofiled user
# the timespan of the actions
# ...

Additionally:
# Brushing
# Linking

====(multidimensional) Scatterplot====
# All Varaibles can be assigned to an axis.
# There is a maximum of 3 variables at the same time.
# There can be used a set of varaibles which is then exchanged continously using a subset of 3 variables out of the selected ones at a time.
# There can be color added to the plot giving additional information (see Parallel Coordinates).

====Morphing====
# Specify start and end point.
# Hit play to let morphing happen within the assigned timespan.
# Hit STOP to set the header to the starting time.
# Hit PAUSE to stop the header at any time.
# Drag and Drop the head to jump to a specific time.
# Switch between an absolute and relative time-axis.

===Description of Used Techniques===
(see above)

===Possibilities of Interaction===
# In any stage of the charts one can make use of the '''timeline''' to focus.
# Hook on on/off checkboxes at the left to include/exclude certain user actions.
# Assign color to charts to represent special groups (e.g. profiled and unprofiled user)
# Assign different symbols (where possible) instead of colors.
# Rotation of subsamples of variables when selecting more than 3 (Scatterplot).
# Zoom to special Bubble down to the one user action.
# Providing user data for the one user on demand and showing data in detail section.

===Mockups / Fake Screenshots===
[[image:Screenshot2_structure.jpg]]
 
 
[[image:Screenshot2_small.jpg]]

----
< [[Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8|G8]] 
<< [[Teaching:TUW_-_UE_InfoVis_WS_2005/06|overview]]

File:MiceRelation.png

2005-11-22T17:54:58Z

UE-InfoVis0506 0325693: Simple flowchart explaining the description of a 1:n relation.

== Summary ==
Simple flowchart explaining the description of a 1:n relation.
== Copyright status ==
[Seyfang, Fritz, Schnabl, 2005]
== Source ==

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T21:41:32Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T21:38:07Z

UE-InfoVis0506 0325693: /* Description of the Datastructures */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T18:01:32Z

UE-InfoVis0506 0325693: /* Description of the Datastructures */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T18:01:18Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T18:01:10Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T18:00:14Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T17:59:00Z

UE-InfoVis0506 0325693: /* Special Issues of the Target Group */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T17:49:12Z

UE-InfoVis0506 0325693: /* Description of the Datastructures */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T17:38:29Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T17:34:43Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-20T15:32:45Z

UE-InfoVis0506 0325693: /* User */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T19:39:30Z

UE-InfoVis0506 0325693: /* Description of the Datastructures */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T19:39:03Z

UE-InfoVis0506 0325693: /* Description of the Datatypes */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T19:37:40Z

UE-InfoVis0506 0325693: /* Description of the Datatypes */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T19:32:24Z

UE-InfoVis0506 0325693: /* Description of the Datatypes */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T19:03:36Z

UE-InfoVis0506 0325693: /* Description of the Datatypes */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T19:00:18Z

UE-InfoVis0506 0325693: /* Description of the Datatypes */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T18:55:41Z

UE-InfoVis0506 0325693: /* Description of the Datatypes */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T18:44:51Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T18:43:04Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T18:37:55Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T18:32:59Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T18:26:29Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T18:05:36Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 3

2005-11-19T18:05:22Z

UE-InfoVis0506 0325693: /* Analysis of the Dataset */

2005-10-25T20:02:07Z

UE-InfoVis0506 0325693:

==Definition(s)==

''Consistency describes a harmonious uniformity or agreement among things or parts.'' [Hyperdictionary.com, 2005]

''Agreement or harmony of all parts of a complex thing among themselves, or of the same thing with itself at different times.'' 
[Whatdowordsmean.com, 2005]

==Key Words==

Consistency, system design, webdesign

==Abstract==
''"Consistency (in Design)" is often referred to as the central criteria for successful user interaction. Any interface wants to keep its user focused, and additionally guide him to a procedure or structure. All this needs a clear and consistent framework of elements within the design of the interface. Consistency can create a distinct sense of "place" and makes parts and functions in a system memorable [Lynch and Horton, 2002]. 
Therefor I want to give a brief overview on the important issues of consistency.''

==Consistency and its Context==

===Important Issues===

The following list tries to give a ranking that indicates which elements of an interface require consistency the most [Bruce Tognazzini, 2003].

# Interpretation of user behavior, e. g., shortcut keys maintain their meanings.
# Invisible structures.
# Small visible structures.
# The overall "look" of a single application or service-splash screens, design elements.
# A suite of products.
# In-house consistency.
# Platform-consistency.
 

It is a common error to assume that the list should be in reverse order, providing interfaces which look similar on the outside, but have a completely different behaviour on the inside. This would lead to major difficulties in usage, and thus endanger the success of the system. [Bruce Tognazzini, 2003]

===Examples: Shortcut Rules===

Due to intensive amounts of time spent working with their computers, users are becoming more and more familiar with shortcut keys to save time. The user does not respond to the feedback provided via screen and has to follow and reposition the mouse-pointer to push a button or close a window any more, but relies on the concept that several special key combinations are inherent of a very powerful set of commands which covers most of the functionality provided by the mouse.
Users tend to enter most of the commands via keyboard whereas to the right (or left) the mouse gets more and more useless.

This way of working would be very efficient if there where not those small inconsistencies which result in some cases in pretty annoying computer behavior. The major problem is that advanced users enter commands in way and a speed which makes it impossible to check whether the computer is reacting in the right way - they just have to rely in the system, and if the commands are not interpreted as usual it is very inefficient to learn this special programs peculiar characteristics.

There are several inconsistencies concerning this problem in the MS Windows and MS Office software packets:

====Example: Incomplete Shortcut Definition====

To give an example for the points mentioned in the list above, I want to refer to Microsoft Windows and its applications as a suite of products (list element 5).

In the Microsoft Windows software and in most of Microsoft's products shortcuts are of the same nature: CTRL+[underlined letter of command]. 
[[Image:Consistency.png]] 

As you can see this gives the impression that the way of treating commands always swings that way. Unfortunatly this is not the case. The next screenshot shows that there are parts of the software where the shortcut rule is violated. This contradicts rule number 5 of the list above. 
[[Image:inconsistency.png]]

This inconsistency leads to a big gap between what the system provides and what the user expects.

====Example: The Microsoft Word CTRL+Tab problem====

The well known shortcut ALT+Tab which switches between the main windows on a user’s desktop has a "little brother" the CTRL+Tab combination, which switches between the single documents in a MDI (Multiple Document Interface) application. The whole application suite of Microsoft supporting MDI from MS Excel to MS Developer Studio and so on supports this command, whereas MS Word does interpret it in it's own way.
It just ignores that the user has pressed the CTRL button and writes a "tab" into the document which is pretty annoying because data may be overwritten. A user working with more than one MS Word document at a time expects the next document to appear but instead of this the currently selected part of the document no matter how many pages it contains is being changed to a single tab.

Although we all are happy about the undo feature, it is tiresome to undo this step and to change the active document manually by mouse.

====Example: The undo/save incompatibility of MS Excel====

A different problem is the undo - save incompatibility of MS Excel: Everyone is used to be able to undo at least the last modifications he made with his documents. Further everyone has learned that it is very useful to save his documents frequently to avoid data loss due to system breakdowns. As already mentioned advanced users do not think about what to do to save a document or do something else, they just think about saving and automatically press the CTRL+S combination.
On the other hand no one cares about deleting or modifying major parts of his/her current work because since many years the undo - possibility has been omnipresent.

The problem occurs in MS Excel and MS PowerPoint if the user relies in both features: If parts of the current document are modified in a way that they cannot be reconstructed without pressing undo and the user saves the document, it is not possible to get back the original data because during saving the undo-history is obviously being deleted.

This wouldn't be a major problem if all programs were working this way, because everyone would assume this behavior. The fact that only some products are reacting this way may cause unwanted data loss just because of inconsistencies which may be avoided very easily.

===Example: Same Appearance, Different Meaning===

Another but in this case minor inconsistency is the fact that the printer function in all MS Office products reacts in different ways although the icon looks 100% the same:

{||
|[[Image:printer_tb.png]] 
[[Image:printer_mn.png]]
|valign=top|
The icon in the File-menu of the application opens a print – dialog where before printing the user may select the printer, the paper size, paper quality and so on.
However the icon in the toolbar immediately starts the printing process without asking for the printer or anything else.
|}
This is only a minor problem but it often causes unwanted paper output just because the user did not think about using the print function in from the menu instead of pushing the toolbar button.
This problem would not appear if both icons would react in the same way no matter what they do. The user would get used to the functionality and it would never happen that he starts the print job without having defined which paper or printer to use.

===Example: Webdesign===

In the context of invisible structures I would like to come up with an example from the field of webdesign. This field is highly dependent on the principles of design, especially ''consistency'', because it has so much freedom in the lookalike of its products.

{||
|[[Image:VBAObjekte.jpg]]
|valign=top|
If you consider programming Visual Basic, you have a predefined suite of objects, which follow a number of design principles already. This example shows how color harmony and a predefined typography can influence the consistency of a set of objects. [Joshua David McClurg-Genevese, 2005]
|}

Engaging in webdesign you will face a tremendous freedom, which also comes along with a great amount of responsibility.

[[Image:Structure.gif]] 
[Lynch and Horton, 2002]

The structural concept above gives an idea how consistency is practically applied. Providing a graphical and logical concept helps the user to remember and assume where he finds the desired information or service inside the system or website. [Lynch and Horton, 2002]

[[Image:Header.gif]] 
[The Bridgeman Art Library, 2003]

An example for a good concept is the header shown above. It was part of the website http://www.bridgeman.co.uk . One can easily recognize that the design of the website is consistent in its typography and lookalike throughout the buttons and page banners [Lynch and Horton, 2002]

==Conclusion==

To sum up it is to say that ''consistency'' is a very important topic in design as a whole, and information design in particular.Knowing your users and providing them with a well structured, logically correct and predictable system is the major aim related to the principle of consistency.

==Bibliography==
[Bruce Tognazzini, 2003]
First Principles of Interaction Design, Nielsen Norman Group, Created at: 2003. Retrieved at: October 22, 2005 
http://www.asktog.com/basics/firstPrinciples.html

[Hyperdictionary.com, 2005]
Consistency. Retrieved at: October 22, 2005 
http://www.hyperdictionary.com/dictionary/consistency

[Whatdowordsmean.com, 2005]
Consistency. Retrieved at: October 22, 2005 
http://www.whatdowordsmean.com/definition/consistency/

[Lynch and Horton, 2002]
Webstyleguide 2nd edition. Created at: 2002. Retrieved at: October 22, 2005 
http://www.webstyleguide.com/page/consistent.html

[Joshua David McClurg-Genevese, 2005]
Design in Theory and Practice, Created at: August 15, 2005. Retrieved at: 24. October, 2005 
http://www.digital-web.com/articles/elements_of_design/

----
< [[Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8 - Aufgabe 1|Aufgabe 1]] 
<< [[Teaching:TUW - UE InfoVis WS 2005/06 - Gruppe G8|G8]] 
<<< [[Teaching:TUW_-_UE_InfoVis_WS_2005/06|overview]]