Everything started with this prototype: structSearch. The goal was to figure out if Flex, and some of its open source libraries, were about to make a good data visualization framework for Structured Dynamics. As it turned out, it was making more than a good data visualization framework, as the Semantic Component Library is now one of the central libraries maintained by Structured Dynamics.

It was about one year ago.

But it is more than a demo, it is more than just a new data visualization framework. It is a set of technologies, it is a process by which you can do data integration, management, publication and visualization faster, better and for a fraction of the price. It is what we do at Structured Dynamics, and we hope continuing to share our findings to help communities to move faster, better and for the best.

What we do here is to demonstrate one of the facet of this new architecture.

strutSearch

The structSearch demo is interesting because it is a good example of what we call an Ontology Driven Application. Basically, the user interface of the application behave differently depending of the data that it gets as input.

In the example below, the structSearch tool gets all its data from a call to a structWSF instance where the Semantic Sweet Tools List dataset is hosted. You can try a search with the acronym “rdf“:

[kml_flashembed publishmethod=”static” fversion=”10.0.0″ movie=”http://fgiasson.com/flex/demos/structSearch/structSearch.swf” width=”500″ height=”700″ targetclass=”flashmovie” fvars=”baseAppUrl=http://fgiasson.com/flex/demos/structSearch/”]

[/kml_flashembed]

Note: if you have issues loading this Flash movie, it may be because the feed reader you are using, and what it does with some of the code within this blog post. I would suggest you to go to the website directly to experiment this tool.

How it works

The general workflow is somewhat simple; it is composed of only three parts:

1.����� A Resultset (which is composed of one or multiple records descriptions)

2.����� An application layout (a MXML file)

3.����� And a rendered user interface

These three steps are shown in this image (click to enlarge):

The complete process is discussed on the TechWiki. The structSearch demo leverages one of the semantic components: the sGenericBox. This box is a generic record infobox: it tries to display all the information related to a record�s description that is not handled by any other part of the application layout layer. So, most of the attributes/values are handled by the application, but for all the remaining, unhandled, attribute/values, they get listed in the generic box.

What is interesting with this three steps workflow that the users starts with one thing: a set of attributes/values describing a record. Then, they build a user interface that binds different attributes to controls that will be used to display their values. Finally, depending on a record’s description, and the application layout, the user interface generated will looks like/behave differently.

Why?

There is no magic in there, and the idea of adaptive user interfaces is certainly not new. However, what I think that people should keep in mind after reading this blog post is that the this specific workflow, along with these specific technologies helps the: integration, management, publication and visualization of different data sources. I hear you saying: yes and what? There are hundred of systems that tries to do this. Yes, that is true. But I would answer to that question with another question: yes, but at what price? By this I mean: can you develop as quickly and effectively as you could with these new methods, processes and technologies?

At least, this is what we figured out.