Zegami’s intuitive interface empowers users to explore their data without the need to learn other complex data tools. While Zegami is extremely useful for displaying large collections of images, not all data sets have images. In keeping with our vision to make sense of data we need a way to represent a data point as a tile.
These tiles or “Zegs” will be dynamic (rendered by the browser) and data-bound (the visual elements of the tile will be tied to the items metadata).
An example Zeg. Where the up and down arrow indicators are based on the % change value from the items metadata.
Zegs can be designed to render different levels of detail based on the size of the Zeg within the view. For example this is useful when the Zegs are very small as only simple colours are recognisable at this level. In the following example the colour of each Zeg is different based on the “Market Segment” value of the dataset.
Zegami has three levels of detail: small, medium and large.
Authoring a Zeg
A combination of and was chosen as the language to define a Zeg. SVG as it is a standard used by many design tools like Illustrator and Inkscape and XSLT as it can be used to databind to and add complex logic to a Zeg.
As a simple example to get started, we can create an svg element that contains a single rect element to draw a coloured box.
<rect y="0" width="68" height="68" fill="#a6bddb"/>
The result is a simple square.
Data binding basics
Because SVG is based on XML it’s possible to use an XSLT transformation to data bind values.
For example if we have a data source with the following values:
Tables can't be imported directly. Please insert an image of your table which can be found here.
We could use an SVG text element to draw the name value onto each Zeg. In order to do this Zegami internally converts a data row into an XML document. Because of this conversion it’s then possible to use to select the values to bind. For example the first row in the table above is converted to:
We can use a combination of the xsl:value-of element with an XPath selector of row/value[@colname='name'] to write the name value.
Which results in:
XSLT supports conditional statements which means it’s possible to render different elements depending on the data values. A simple example of this is changing the fill colour of the rect element. This can be done by using a combination of the xsl:choose and xsl:when elements
The SVG image element is supported so that images can be mixed in with dynamic content. To support externally referenced images an additional xmlns:xlink namespace need to be placed on the SVG element
The xlink:href attribute can then be used to point to an external image resource. This can also be combined with an XPath selector for dynamic images.
For security reasons browsers will block image content that is loaded from a domain that is different from the host. In this scenario images will not be loaded. The current work around is to create a server side proxy which can fetch the images.
When rendering very small tiles it doesn't make sense to have highly detailed Zegs as often the detail cannot be seen and it hurts overall application performance. So that it’s possible to create Zegs Zegami includes an attribute called size into the XML object which can then be used with a conditional element.
size can either be: small, medium or large.
For example to display the name text only when the tile is large:
Optimising Zegs is critical for achieving smooth, jank-free rendering within Zegami. Poorly designed Zegs limit the total number of items that can be displayed and give a generally bad user experience.
To help the rendering engine optimise each Zeg it is possible to add optimisation hints to the xml in the form of xsl:variable elements. These variables allow Zegami to know which data columns are needed at a particular level. Once the columns are known by Zegami it then is able to utilise a cache to greatly speed up rendering time.
Optimisation hints have a simple naming convention so that they do not impact on other user defined variables. Variable names need to be in the format: key_[level name]. For example to define an optimisation hint for the small level an xsl:variable can be declared with the name of: key_small.
The select attribute of the variable then needs to be an XPath query for the column name(s) that are required to render to Zeg at the level name specified. For example in the conditional elements example above the fav colour column was used to render a simple colour when size was small or medium. We can tell Zegami to optimise for only the fav colour column by specifying a variable like:
Which will then create cached versions of each Zeg for every unique value of fav colour (in our case there are only 3). If a level required multiple columns then they can be concatenated together.
It’s also possible to optimise for ranges of values by using operators to create a boolean expression.
Finally, making the use of the size value to render as little as possible for small and medium levels will greatly improve overall application performance.
Occasionally you might find it desirable to clip information such that text does not overflow given boundaries. This can be achieved using SVG clip paths or alternatively by using transforms to tweak the text data to include an ellipsis after a set number of characters.
To create a clip path, you can wrap drawing functions inside a <clipPath> object. Objects can reference a clip path so that parts of the drawn object outside of the clip region are not shown. The effect is similar to using cookie cutters when baking, you define the shape with your clip path. See the following example:
Now in the example below, we draw a shaded rectangle to show the effect of clipping.
This approach is a more simple alternative to trimming the text itself. There is not an elegant way of doing text wrapping with XSLT transforms, a rational approach is to define a limit of characters and then append an ellipsis in the event that the length of the text data exceeds this. You can use the substring XSL function along with an XSL if statement to achieve this. For example, see the following code:
The code above declares the limit variable, which is used in both instances. The underscore tells the dynamic tile plugin to ignore it, otherwise they may be misinterpreted as keys or flags.
The net result is that long text is truncated, with a trailing ellipsis in the event that the text was actually cut off.
Creating a variable for a color is a great way to make the XSLT more readable and allows for reuse of fills and other color attributes.
For example to set the colors based on the values in a column called Overall.
It can then be used to set the fill color for a rectangle.
Tips for authoring with Inkscape
Inkscape is a free, vector based, drawing tool that naively supports SVG files. Using Inkscape is a great way to produce high quality Zegs without having to spend too much time creating an SVG problematically. However there are a few things to keep in mind.
First in Document Properties set the Display units and Units to ‘px’. Then set the size of the svg, making sure the scale is 1 and the Viewbox is the same. This makes the units all sensible so that it's easier to make code level tweaks when converting to XSLT.
Quite often it adds annoying top level group transforms which can make it tricky to make adjustments when creating the xslt. To get around this, open the XML Editor (Edit > XML Editor), find the node and then delete the transform attribute from the g node.
When saving make sure that the type is Optimized SVG as this removes 90% of the junk that Inkscape adds to the file.
We’ve also found that radial gradients and masks don’t work. Also linear gradients fail in IE. Once the SVG markup is sensible then it’s usually fairly straight forward to add the XSLT.