My name is Ismael Chang Ghalimi. I build the STOIC platform. I am a stoic, and this blog is my agora.
We’ve moved the Cases object from STOIC CRM to the platform, because many applications need it, beyond pure CRM use cases. We’ve also replaced the STOIC Requests tool by a new STOIC Cases tool, since the Requests object is nothing more than a simplified version of the Cases object.
We’ve moved the Cases object from STOIC CRM to the platform, because many applications need it, beyond pure CRM use cases. We’ve also replaced the STOIC Requests tool by a new STOIC Cases tool, since the Requests object is nothing more than a simplified version of the Cases object.
We’ve moved the Cases object from STOIC CRM to the platform, because many applications need it, beyond pure CRM use cases. We’ve also replaced the STOIC Requests tool by a new STOIC Cases tool, since the Requests object is nothing more than a simplified version of the Cases object.
We’ve moved the Cases object from STOIC CRM to the platform, because many applications need it, beyond pure CRM use cases. We’ve also replaced the STOIC Requests tool by a new STOIC Cases tool, since the Requests object is nothing more than a simplified version of the Cases object.
We’ve moved the Cases object from STOIC CRM to the platform, because many applications need it, beyond pure CRM use cases. We’ve also replaced the STOIC Requests tool by a new STOIC Cases tool, since the Requests object is nothing more than a simplified version of the Cases object.
We’ve moved the Cases object from STOIC CRM to the platform, because many applications need it, beyond pure CRM use cases. We’ve also replaced the STOIC Requests tool by a new STOIC Cases tool, since the Requests object is nothing more than a simplified version of the Cases object.

We’ve moved the Cases object from STOIC CRM to the platform, because many applications need it, beyond pure CRM use cases. We’ve also replaced the STOIC Requests tool by a new STOIC Cases tool, since the Requests object is nothing more than a simplified version of the Cases object.

Victory! This is ugly as can be, but it shows that our new Map perspective is now capable of showing Geoshapes. What you’re seeing here is the Regions object (3,485 records), which includes all 250 countries. For these, we’ve populated their Geoshape field values with the GeoJSON of all countries. Then, we bound this field to the Location dimension of the Map perspective, and this is what you get as a result.

What’s the empty area on the East side of the Horn of Africa? It’s Somaliland, which Wikipedia describes as a self-declared independent state that is internationally recognised as an autonomous region of Somalia. Therefore, we can’t really consider it as a country (our rule for that is that it has to be recognized by the UN), and we need to add its GeoJSON shape to the one used for Somalia. Good news: we support all types of GeoJSON shapes, including MultiPolygons.

With this in place, our GIS capabilities are getting good enough for STOIC Maps.

Check this out! We now have support for Perspective Parameters. That is, parameters defined for a perspective such as Map within the context of a view (Destinations by Duration in this case). Some parameters of the Map perspective remain to be implemented, but the core framework is in place, courtesy of François. This is some really powerful stuff here…
Check this out! We now have support for Perspective Parameters. That is, parameters defined for a perspective such as Map within the context of a view (Destinations by Duration in this case). Some parameters of the Map perspective remain to be implemented, but the core framework is in place, courtesy of François. This is some really powerful stuff here…
Check this out! We now have support for Perspective Parameters. That is, parameters defined for a perspective such as Map within the context of a view (Destinations by Duration in this case). Some parameters of the Map perspective remain to be implemented, but the core framework is in place, courtesy of François. This is some really powerful stuff here…
Check this out! We now have support for Perspective Parameters. That is, parameters defined for a perspective such as Map within the context of a view (Destinations by Duration in this case). Some parameters of the Map perspective remain to be implemented, but the core framework is in place, courtesy of François. This is some really powerful stuff here…

Check this out! We now have support for Perspective Parameters. That is, parameters defined for a perspective such as Map within the context of a view (Destinations by Duration in this case). Some parameters of the Map perspective remain to be implemented, but the core framework is in place, courtesy of François. This is some really powerful stuff here…

Here is our second STOIC Tools website. Why does it matter? Because it proves that our template can work for any of the 60 tools that we are currently crafting. All that is needed after that is some well-defined meta-data, and STOIC Pages does the rest. Awesome!

François and I are now working on the auto-layout algorithm for our new Process Editor. You can see the steps of a test process on the first screenshot, what it should look like on the second screenshot, and what the dendrogram for the process looks like on the third screenshot.
The primary goal of the algorithm is to prevent any line crossing while minimizing the vertical space used by the process. In order to keep things simple, back loops will not be drawn. Instead, we will just depict them with a specific icon that can be clicked on in order to highlight their respective targets. Quick and easy…
We should have a first version of the algorithm today or Monday next week.
François and I are now working on the auto-layout algorithm for our new Process Editor. You can see the steps of a test process on the first screenshot, what it should look like on the second screenshot, and what the dendrogram for the process looks like on the third screenshot.
The primary goal of the algorithm is to prevent any line crossing while minimizing the vertical space used by the process. In order to keep things simple, back loops will not be drawn. Instead, we will just depict them with a specific icon that can be clicked on in order to highlight their respective targets. Quick and easy…
We should have a first version of the algorithm today or Monday next week.
François and I are now working on the auto-layout algorithm for our new Process Editor. You can see the steps of a test process on the first screenshot, what it should look like on the second screenshot, and what the dendrogram for the process looks like on the third screenshot.
The primary goal of the algorithm is to prevent any line crossing while minimizing the vertical space used by the process. In order to keep things simple, back loops will not be drawn. Instead, we will just depict them with a specific icon that can be clicked on in order to highlight their respective targets. Quick and easy…
We should have a first version of the algorithm today or Monday next week.

François and I are now working on the auto-layout algorithm for our new Process Editor. You can see the steps of a test process on the first screenshot, what it should look like on the second screenshot, and what the dendrogram for the process looks like on the third screenshot.

The primary goal of the algorithm is to prevent any line crossing while minimizing the vertical space used by the process. In order to keep things simple, back loops will not be drawn. Instead, we will just depict them with a specific icon that can be clicked on in order to highlight their respective targets. Quick and easy…

We should have a first version of the algorithm today or Monday next week.

The style of a Geoshape on the Map perspective or on the Geoshape control can now be configured either from the options of the Geoshape datatype (default style for all Geoshape), from the options of a particular Geoshape field (default style for all values of the field), or directly from a Geoshape value. This style includes:
The thickness of the line
The color of the line
The opacity of the line
The color of the background
The opacity of the background
The style of a Geoshape on the Map perspective or on the Geoshape control can now be configured either from the options of the Geoshape datatype (default style for all Geoshape), from the options of a particular Geoshape field (default style for all values of the field), or directly from a Geoshape value. This style includes:
The thickness of the line
The color of the line
The opacity of the line
The color of the background
The opacity of the background

The style of a Geoshape on the Map perspective or on the Geoshape control can now be configured either from the options of the Geoshape datatype (default style for all Geoshape), from the options of a particular Geoshape field (default style for all values of the field), or directly from a Geoshape value. This style includes:

  • The thickness of the line
  • The color of the line
  • The opacity of the line
  • The color of the background
  • The opacity of the background

UI roadmap

For the next two months, we’ll split our UI development efforts into two main streams of work: refactoring and tools. Florian will take the lead on the refactoring front, while François will develop our tools engine and the handful of custom editors that are needed for various tools.

Refactoring

We will work on three main projects:

First, we will migrate from AngularJS 1.1.5 (which is more than one year old) to a newer version, either the stable 1.2.23, or the newer 1.3.0-beta.19. The main difference between 1.2 and 1.3 is that support for Internet Explorer 8 is dropped from 1.3, therefore we might stick to 1.2 for now, and wait for 2.0 before making a bigger jump. This work will start next week and will keep Florian busy until we’re done with it.

Second, we will add support for webpack in order to further modularize our code. We’ll package all our shiny editors with it, and we’ll get rid of our giant controller.js file, which has been growing out of control over the past two years. Florian will also take the lead on that project, even though most of the work will actually be done by François.

Third, we will add support for incremental meta-data cache loading. So far, we load the entire meta-data cache all at once, and do incremental upgrades. This is great, but it’s not enough, because our meta-data cache got too big. We looked at ways that we could make it smaller, but about half of it simply comes from the Fields object. Therefore, even if we were to remove some objects from it, it would not really solve the main problem.

To really get a significant reduction of our cache’s size when loading our user interface, we need to incrementally load its content as we need it. And since we’re taking a tools-oriented approach for our user interface, we usually need meta-data for only a few objects at a time, therefore this refactoring is very timely. This is by far our most ambitious refactoring project, and it will keep Florian busy for most of September and possibly October, with some adult supervision to be provided by Pascal, and some loud cheerings by Hugues.

Tools

On the tools front, we will start by polishing the following editors:

  • Object Editor
  • Chart Editor
  • Sensor Editor
  • Database Editor (from the ERD generator)

We will then develop the six missing editors we need, in this order:

  • Authorization Editor
  • Score Editor
  • Story Editor
  • Composite Editor
  • Rule Editor
  • Scraper Editor

But before we do the new editors, we will implement hierarchical grouping and a pivot table.

The former should not be confused with multi-level grouping, which is already supported in the Grid perspective. Hierarchical grouping is used with objects that are defined with a hierarchy, and for which you need groupings and aggregations to be done at any level of the hierarchy. This project should take a solid week to complete.

The latter is a multi-dimensional pivot table. I still need to figure out exactly how it will work, but you could think of it as a way to do multi-level aggregations in the Grid perspective across two dimensions, vertically across records as we do today, and horizontally across fields as needs to be added. Things will get a bit clearer on this front after I spend a week-end giving it some more thoughts. This project should take at least two weeks.

In other words, we will:

  • Get a first version of our 60 tools
  • Implement hierarchical grouping
  • Implement the pivot table
  • Get better editors for 6 tools

Altogether, François will need a solid 12 weeks to do all this, which will take us to November.

And once Florian is done with his refactoring work, he will work on integrating the View Editor with all our perspectives, so that views can be created from any perspective, not just the Grid one. He will also work on blending charts and perspectives so that charts can be displayed on a perspective (charts on a map for example), and so that perspectives can be used for displaying aggregated data instead of just raw data (perspectives acting as charts really). All this should keep him pretty busy for a month or two…

After much back and forth discussions, we finally managed to fix our Geoshape control, which was handling longitudes and latitudes the wrong way. GeoJSON expects longitude first, latitude second, while Google Maps does the reverse. Everything is in order now…
After much back and forth discussions, we finally managed to fix our Geoshape control, which was handling longitudes and latitudes the wrong way. GeoJSON expects longitude first, latitude second, while Google Maps does the reverse. Everything is in order now…

After much back and forth discussions, we finally managed to fix our Geoshape control, which was handling longitudes and latitudes the wrong way. GeoJSON expects longitude first, latitude second, while Google Maps does the reverse. Everything is in order now…