Comments (16) Visits (9720)
We will blog over the next days to provide more details on each of the topics.
We look forward to getting feed-back from you all!
Comments (13) Visits (8525)
To answer numerous questions we get, here is information matrix:
Pricing for ISV / OEM uses: (i.e. charging fee for your application use)
Pricing for all other uses: (e.g. intranet or free public facing applications)
Comments (7) Visits (9701)
As Adobe Flex 4 (on which is based IBM ILOG Elixir 3.0 beta) requires Flash Player 10, Adobe had the good idea to leverage the Flash Player 10 3D API and made part of it available through some properties on the core
Actually doing so is just a few properties on the components. So let's have a look at it.
By default the IBM ILOG Elixir Timeline is created as follows:
And will render front facing (click on the image to get the live example):
As any standard Flex component you can use 3D rotation on the Timeline as the corresponding properties are available on the
Note that in addition to
Finally for the event renders in the Timeline to be easily readable we want them to be front facing and not subject to perspective, that's why on the
Using this the result is now the following (click on the image to get the live example):
This same strategy can be applied to any Flex standard component like Spark Button or any IBM ILOG Elixir component. However this is not always as meaningful as for the Timeline so don't forget to apply this wisely
Comments (6) Visits (6742)
Earlier this week we announced the release of Elixir Enterprise version 3.5. Some highlights of this new release include:
If you're interested in checking out the new version, the 90-day trial of Elixir Enterprise will be updated next with the latest enhancements.
Comments (4) Visits (5909)
When using Elixir Enterprise diagramming components you would sometimes like to share what you get on screen with other team members or customer.
A first solution is to print the graph on paper, using the appropriate APIs. But maybe it is something we should avoid on a... smart planet
An other way to share content, is to serialize the diagram in a file, as it is illustrated in samples like "Network Editor" or "BPM editor". But it needs a similar application to open and visualize the file.
Thus, we are going to describe the next obvious solution, which is to export the content of the graph in a bitmap file that you could share.
Like many softwares displaying information on screen it is possible to export the graph's content in a bitmap file. This feature is not included in the APIs but you can achieve that with few lines of code.
Whatever the component hierarchy you instanciated in your application to embed the graph, it needs to understand that it is the content of the graph that will be converted as bitmap. Thus we will always acces to the instance of Graph class that is finally used.
For the purpose of this explanation we consider using a Diagram instance in our sample. The Diagram is a skinnable component containing several containers, but the API gives us access to the graph instance contained in the Diagram.
The following code creates a Diagram with a set of nodes and links
<fx:Object id="node2" name="Node2" />
<fx:Object id="node3" name="Node3" />
<fx:Object id="node4" name="Node4" />
<fx:Object id="node5" name="Node5" />
<fx:Object id="node6" name="Node6" />
<fx:Object id="node7" name="Node7" />
<fx:Object id="node8" name="Node8" />
<fx:Object id="node9" name="Node9" />
<fx:Object id="node10" name
Here is what we get on screen:
Because the node coordinates are not explicitly defined they are all (0,0) by defaut. The layout algorithm (TreeLayout) will use the root node (Node1) to arrange the tree, and because it is in (0,0) it explains why some parts of the graph, located in negative coordinates, are not visible . The graph is not scrolled in order to keep this representation and to illustrate that the whole graph's content will be exported as bitmap.
Now let's save this graph in a bitmap file. We are using standard classes and APIs provided by Adobe Flex plateform: a raw bitmap data structure to store the image, and a bitmap encoder to save these data in a file. All following code samples could be put in the click event handler of a Button.
First, we create a bitmap data for the graph image. This is an instance of flas
var bbox:Rectangle = diag
The next step is to draw the graph in the bitmap data, but if we directly draw it, the hiddent part will not be drawn because of the negative coordinates. In this case it will be more like a screen capture and not a "export to" feature.
Thus it needs to perform a translation during the drawing process to put the entire graph's content in the bitmap data.
var matrix:Matrix = new Matrix(); // creates a transform matr
We now have a raw bitmap data representation of the graph which is ready to be saved in a file.
But what will be the exported bitmap format? Flex provides two useful classes to encode raw bitmap data in specific formats: PNG and JPEG. Let's choose the PNG format and its associated encoder, the mx.g
var encoder:PNGEncoder = new PNGE
Starting guide for nice diagrams: quick hints for choosing a graph layout algorithm for the Diagram component
Comments (4) Visits (6166)
Now, we may wonder: with automatic arrangement of diagrams, humans (developers or end-users) have no role to play anymore? Well, don't worry, there is still place for humans taking decisions. These decisions concern basically two kind of choices that are in the hands of the developer (alternatively, if appropriate, the developer can offer these choices to the end-user thanks to configuration GUI):
The present post focuses on the first point: how to chose the graph layout algorithm that fits. In some cases, this choice is quite straight-forward, in other cases it is a bit trickier, and to guide your choice you can find below a short synthesis of information present at various places in the Elixir Enterprise documentation (Reference and User Manual), enriched with a few additional hints.
This algo organizes the nodes in horizontal or vertical levels, in such a way that the majority of the links flow uniformly in the same direction. A typical example:
This algo is the obvious choice for representing hierarchies, that is for hier
The obvious choice for representing trees (such as organization charts), where each node has one single ancestor. A typical example:
Can also be used if the graph is not a (pure) tree, however in this case the Tree layout only takes care of the shape of part of the links (those that contribute to the pure tree part of the graph, the so-called "spanning tree" of the graph).
Your graph does not represent a hierarchy, is not a tree and the orientation of links does not matter? Then Force-Directed layout is likely to fit. An example:
A remark, however. For large graphs (say, with thousands of nodes), this algorithm is much slower than Hierarchical or Tree layout. Therefore, for performance reasons, you may prefer using them for such graphs, even though the graph is not a Hierarchy nor a Tree.
Obvious choice in case your graph has no links at all, or you want nodes to be placed on a grid or matrix while ignoring the links. An example:
Short and Long link layout
Both are link layouts, that is they do not move the nodes, they only reshape the links in such a way that crossings and overlaps are reduced or avoided. But why two different algos, Short link layout and Long link layout? The answer is that they have different (mostly complementary) characteristics, and, depending on the case, one or the other provides results that fit better the aesthetic and performance requirements. How to chose one or the other? The dumb rule is to try any of them; if it does not fit, try the other one (and explore the multiple options of each).
That said, it is also useful to be aware of some characteristics of each, which help making the choice. In very brief, the names "Short Link layout" and "Long Link layout" refer to the fact that the first one fits better when most links are "short", that is they interconnect relatively close nodes, without too many other nodes placed as obstacles that would need to be avoided by the path of the link. It is the converse for "Long Link layout": it usually fits better when links connect distant nodes with many obstacles in-between.A more in-depth comparison follows:
Short Link layout
Long Link layout
The two screenshots above hold for the same graph. At a quick look, the results of the two link layouts are pretty much similar, but a closer look, many details are different in terms of link-link crossings, link-node overlaps, symmetry of connection points with respect to the node box, number of link bends (how many turns).
Comments (3) Visits (6246)
If you are like me used to read online documentations more often than the ones installed on your disk, I have a good news for you. Indeed the IBM ILOG Elixir Enterprise 3.5 documentation can now be found online at the following url: http
Comments (2) Visits (9444)
In IBM ILOG Elixir 3.5, we had the opportunity to re-write the calendar as spark component. The component is compatible with Flex SDK 4.5.x.
The keyword for this component is "flexibility", you will understand why in the next sections.
Here is an non exhaustive list of new or improved features:
First of all, the calendar is a real spark component which means that you can customize any pixel of the component.
At the contrary of the previous version which was a sort of black box, you have access to the internals of the calendar, its sub components, how they are placed, how they are rendered etc.
By accessing the Calendar skins you can:
Here are three different skins applied on the same component instance.
The default skin (click on image to enlarge it)
The spark calendar provides sub components (row header, column header, grid, data groups, layouts etc.) and base classes and building bricks to create your own skins.
Multiple calendar display in column view
In the previous versions, the color of the item renderers was used to differentiate two items that are belonging two different calendar.
In addition to colors, in order to easily compare items from two different calendars, the new component can, for each column representing a day, display a sub column per calendar.
When time is selected in sub columns, you can easily determine the associated calendar, for example to create a task on the selected calendar.
Type of view and time range are not correlated
The calendar's core job is to display events in time through different views. In MX calendar, the kind of view is determined by the duration of the queried time range. This is not the case anymore, now you specifies the time range to display and the display mode: columns or grid.
For example this kind of view were not possible in previous versions:
Time range definition
To set the time range, you can:
Item / renderer association
Before the kind of renderer (vertical, bar, horizontal or label) was hard-coded according to event duration.
Now you can specify the kind of renderer to use for each item using a simple custom function. It is very easy and very powerful.
Here are some examples where the default behavior is overridden:
Here are some screen shots of usage of the renderer kind custom function:
The Calendar components now has the ability to filter out some days of week.
Here are some example of usage of day filtering:
Time of day filtering
Another feature often asked is the ability to choose the first and last hour displayed in the view.
In grid display mode, it only applies on horizontal renderers and not labels.
Only the 8am to 6pm part of the day is displayed: the left side of a cell is 8am and the right side is 6pm.
Minimal sizes supported
If an event is very short is may not be readable. If readability is more important for you than exact time projection on the screen, the layout is now supporting a minimal height or width.
With a minimal height, the event is visible but its end is not correctly projected so the label must include end time.
New grid display mode layout properties
In grid display mode, it is now possible to configure the layout to make the horizontal renderer to fill cells.
The horizontal renderer can now overlap each other like in columns display mode.
The definition of working and non working periods is now delegated to dedicated object.
This work calendar allows to:
As this work calendar is also used in the Gantt chart components (resource chart and task chart), it allows a seamless integration of the calendar component in an application using these two components.
New animation engine
The new architecture allows to create new animations:
The sole transition that is not animated is from one display mode to another.
Comments (2) Visits (7800)
While discussing with Damien data visualization components not yet available in Flex / Spark, we encountered the Bullet Graph component which is basically trying to mix some of the bar graph and horizontal gauge concepts to take the best of both worlds and convey data information in a more efficient way. The component was first described by Stephen Few in its Information Dashboard Design book. You'll find more information on the bullet graph on its Wikipedia page or in its specification.
Studying bullet graph in a bit more details we realized we actually already had the component in Flex and more precisely in IBM ILOG Elixir. Indeed our gauges are based on the Flex Spark framework and thus are entirely skinnable. That means one can define an IBM ILOG Elixir horizontal gauge and make sure its skin is matching the specifications of a bullet graph. That's how came the idea of creating a series of three short blog posts explaining how to create a bullet graph using ILOG Elixir. You are reading the first post of this series, the next two ones should come quickly in the following days so keep an eye on the blog.
In the end, what we want to achieve is something that looks like this example of bullet graph available on Wikipedia (with explanations in red):
The first step in order to achieve this is to use the ILOG Elixir gauge wizard integrated into Flash Builder in order to create a Flex gauge component that contains all the core properties available on a bullet graph:
For that you need to launch Flash Builder 4 and create a Flex application project. You can right click the project to add IBM ILOG Elixir libraries to the library path. Once this is done, one more right click and you choose the "New > IBM ILOG Elixir Gauge" menu as shown below:
After that, a wizard appears on your screen. The first page asks for the name of the gauge, in our case we will call it BulletGraph. Then when you press "Next", a second page appears that you will need to fill with the core information of a bullet graph:
In the bullet graph use-case the gauge contains a single linear scale that we define in the topmost part of the page. On the bottom part we define the other core properties of the bullet graph. This includes the performance measure or value of the bullet graph that will be displayed in "Bar" mode per specification. This also includes the comparative measure or target that will be displayed in "Marker" mode and the two qualitative ranges that are represented by the grayed area on the bullet graph.
Once we have set these properties we press the "Finish" button and this generates two more files in our application:
These two files are key part of every component that relies on Flex Spark architecture. Each Spark component both have a core component and a skin in charge of its rendering. Among the numerous advantages of this architecture the main one is that it easily allows to switch the rendering of a given component by a different one. That's what we will leverage in the next blog post by replacing the default skin rendering by a rendering that matches the bullet graph specification.
But for now let's keep the default rendering. In order to see the BulletGraph component we need to fill the main.mxml application file with some code instantiating it. We also link the BulletGraph with its skin using the skinClass attribute and we specify its title, target and value in order for them to be displayed as specified in the Wikipedia image bullet graph we want to mimic.
<?xml version="1.0" encoding="utf-8"?>
We get the following rendering:
As you can see even if all the core properties we are interested in are present, this is still not really looking like a bullet graph thus the additional skinning work we will do in the next blog post!
Comments (2) Visits (7640)
The new Spark gauges module available in IBM ILOG Elixir 3.0 lets you customize the look and feel of your gauge by writing your own skin in FXG and MXML graphics.
In this blog post, we will focus on the skinning of rectangular gauges with a bar marker (like a progress bar).
Let's start with a quick and short Q&A on gauges skinning.
Question. GaugeBase defines only one skin part (titleDisplay). Where are skin parts for scales, markers and tracks?
Answer. The Spark component model provides two types of components:
A gauge component is neither fitting exactly -1- nor -2-. Indeed a generic gauge in a framework does have a skin like in -1- defined by the end user, and does have an arbitrary number of parts (scales, markers, tracks) like in -2- but there are not created based on dynamic data, there are created when skinning the gauge.
In order to solve this, we have implemented a specific mechanism which lets you define "dynamic skin parts": A gauge (which inherits from
The following illustration recaps the "partId" mechanism.
Question. What happens to the skin when setting the value of the gauge?
Answer. When you set the value of a gauge, the marker class (a Rect
Question. How do I write rectangular gauge skins which support resizing with no deformation?
Answer. There are two main approaches to write resizable skins:
It's time to see how to build this discrete marker bar using a mask. The idea is to associate to the
<s:Group top="0" bottom="0">
When the value of the gauge changes, the mask is resized and makes the background rectangle partially visible.
To define the mask, we use the
Click here to start the sample, and start playing with the VU meter, you will need a http mp3 URL, Google is your friend... :)