My name is Ismael Chang Ghalimi. I fight against software illiteracy. I am a stoic, and this blog is my agora.
This is just a testing screen, but it shows that we managed to fix some bugs with the fork of SlickGrid we’ve been using for implementing our new view editor. Multi-row and multi-column freeze is working, and we fixed grouping. Now, François can start working on the real thing, while, Florian and I are debugging the new view engine. More on this in a follow-up post…

This is just a testing screen, but it shows that we managed to fix some bugs with the fork of SlickGrid we’ve been using for implementing our new view editor. Multi-row and multi-column freeze is working, and we fixed grouping. Now, François can start working on the real thing, while, Florian and I are debugging the new view engine. More on this in a follow-up post…

It’s not really pretty yet, but this screenshot shows the timeline in action, embedded as a dashlet within a dashboard. Where it gets interesting is that the timeline is now fully packaged as a perspective, which is itself rendered against a view (with filtering), which is itself created from a composite, which is itself aggregating the records of multiple objects and views… For its part, the dashboard is fully responsive, with user-defined layouts designed in plain HTML. The dashboard layout framework supports horizontal or vertical layouts made of multi-cell blocks. The size of blocks and cells can either be absolute or relative. For example, here is the HTML and JSON code defining the layout for the dashboard shown above. As you would expect, both the HTML and JSON are stored in the dashboard’s record, using the Layout and Definition fields (Cf. Dashboard object). Another interesting thing is the fact that we added a new Document widget which allows you to display the content of any Page (to be renamed Document) within a dashlet, which itself can be displayed on any dashboard. The page is served by STOIC CMS and can contain custom client-side JavaScript code. This simple feature is actually quite meaningful, because most of the user interface is made of dashboards now, which François added today at the following levels: Home Application Module Object Record As a result, most of the user interface’s content can now be fully customized by combining widgets, without having to write any code, and custom dashlets can be developed without having to change any server-side code. And since the entire user interface is built using Bootstrap, you can also customize its theme. How cool is that?
It’s not really pretty yet, but this screenshot shows the timeline in action, embedded as a dashlet within a dashboard. Where it gets interesting is that the timeline is now fully packaged as a perspective, which is itself rendered against a view (with filtering), which is itself created from a composite, which is itself aggregating the records of multiple objects and views… For its part, the dashboard is fully responsive, with user-defined layouts designed in plain HTML. The dashboard layout framework supports horizontal or vertical layouts made of multi-cell blocks. The size of blocks and cells can either be absolute or relative. For example, here is the HTML and JSON code defining the layout for the dashboard shown above. As you would expect, both the HTML and JSON are stored in the dashboard’s record, using the Layout and Definition fields (Cf. Dashboard object). Another interesting thing is the fact that we added a new Document widget which allows you to display the content of any Page (to be renamed Document) within a dashlet, which itself can be displayed on any dashboard. The page is served by STOIC CMS and can contain custom client-side JavaScript code. This simple feature is actually quite meaningful, because most of the user interface is made of dashboards now, which François added today at the following levels: Home Application Module Object Record As a result, most of the user interface’s content can now be fully customized by combining widgets, without having to write any code, and custom dashlets can be developed without having to change any server-side code. And since the entire user interface is built using Bootstrap, you can also customize its theme. How cool is that?

It’s not really pretty yet, but this screenshot shows the timeline in action, embedded as a dashlet within a dashboard. Where it gets interesting is that the timeline is now fully packaged as a perspective, which is itself rendered against a view (with filtering), which is itself created from a composite, which is itself aggregating the records of multiple objects and views…

For its part, the dashboard is fully responsive, with user-defined layouts designed in plain HTML. The dashboard layout framework supports horizontal or vertical layouts made of multi-cell blocks. The size of blocks and cells can either be absolute or relative. For example, here is the HTML and JSON code defining the layout for the dashboard shown above. As you would expect, both the HTML and JSON are stored in the dashboard’s record, using the Layout and Definition fields (Cf. Dashboard object).

Another interesting thing is the fact that we added a new Document widget which allows you to display the content of any Page (to be renamed Document) within a dashlet, which itself can be displayed on any dashboard. The page is served by STOIC CMS and can contain custom client-side JavaScript code. This simple feature is actually quite meaningful, because most of the user interface is made of dashboards now, which François added today at the following levels:

  • Home
  • Application
  • Module
  • Object
  • Record

As a result, most of the user interface’s content can now be fully customized by combining widgets, without having to write any code, and custom dashlets can be developed without having to change any server-side code. And since the entire user interface is built using Bootstrap, you can also customize its theme.

How cool is that?

The grid perspective now supports frozen columns. It does not look like much, but it’s actually very tricky, because of the way the grid perspective is implemented. This was made possible by using a fork of SlickGrid (demo). Rows can be frozen as well, thereby creating four areas on the grid (NW, NE, SE, SW). This fork was never merged with the main SlickGrid codebase because it breaks quite a few features, including grouping. François is trying to fix it so that we could use it to build the new view editor and the Gantt perspective, which we want to get ready before the upcoming Project Management Dojo.
The grid perspective now supports frozen columns. It does not look like much, but it’s actually very tricky, because of the way the grid perspective is implemented. This was made possible by using a fork of SlickGrid (demo). Rows can be frozen as well, thereby creating four areas on the grid (NW, NE, SE, SW). This fork was never merged with the main SlickGrid codebase because it breaks quite a few features, including grouping. François is trying to fix it so that we could use it to build the new view editor and the Gantt perspective, which we want to get ready before the upcoming Project Management Dojo.
The grid perspective now supports frozen columns. It does not look like much, but it’s actually very tricky, because of the way the grid perspective is implemented. This was made possible by using a fork of SlickGrid (demo). Rows can be frozen as well, thereby creating four areas on the grid (NW, NE, SE, SW). This fork was never merged with the main SlickGrid codebase because it breaks quite a few features, including grouping. François is trying to fix it so that we could use it to build the new view editor and the Gantt perspective, which we want to get ready before the upcoming Project Management Dojo.

The grid perspective now supports frozen columns. It does not look like much, but it’s actually very tricky, because of the way the grid perspective is implemented. This was made possible by using a fork of SlickGrid (demo). Rows can be frozen as well, thereby creating four areas on the grid (NW, NE, SE, SW). This fork was never merged with the main SlickGrid codebase because it breaks quite a few features, including grouping. François is trying to fix it so that we could use it to build the new view editor and the Gantt perspective, which we want to get ready before the upcoming Project Management Dojo.

Here are some screenshots of our refactored user interface: Custom forms Custom tabs in custom forms Refactored info tab Navigation through relationships Infinite scrolling in the Object View Moom-like controls for setting the relative sizes of screen areas Loving it…
Here are some screenshots of our refactored user interface: Custom forms Custom tabs in custom forms Refactored info tab Navigation through relationships Infinite scrolling in the Object View Moom-like controls for setting the relative sizes of screen areas Loving it…
Here are some screenshots of our refactored user interface: Custom forms Custom tabs in custom forms Refactored info tab Navigation through relationships Infinite scrolling in the Object View Moom-like controls for setting the relative sizes of screen areas Loving it…
Here are some screenshots of our refactored user interface: Custom forms Custom tabs in custom forms Refactored info tab Navigation through relationships Infinite scrolling in the Object View Moom-like controls for setting the relative sizes of screen areas Loving it…
Here are some screenshots of our refactored user interface: Custom forms Custom tabs in custom forms Refactored info tab Navigation through relationships Infinite scrolling in the Object View Moom-like controls for setting the relative sizes of screen areas Loving it…
Here are some screenshots of our refactored user interface: Custom forms Custom tabs in custom forms Refactored info tab Navigation through relationships Infinite scrolling in the Object View Moom-like controls for setting the relative sizes of screen areas Loving it…
Here are some screenshots of our refactored user interface: Custom forms Custom tabs in custom forms Refactored info tab Navigation through relationships Infinite scrolling in the Object View Moom-like controls for setting the relative sizes of screen areas Loving it…

Here are some screenshots of our refactored user interface:

  • Custom forms
  • Custom tabs in custom forms
  • Refactored info tab
  • Navigation through relationships
  • Infinite scrolling in the Object View
  • Moom-like controls for setting the relative sizes of screen areas

Loving it…

If you can understand this mockup, consider yourself a robot. This is a draft for the upcoming Composite View Editor. What it does is pretty cool: you select a perspective (Timeline here) and a set of sources (objects or views), and it automatically creates an object model for a virtual object (aka Composite View), which is then mapped to the fields of sources (objects or views) and the dimensions of all the perspectives supported for the selected sources (based on the datatypes of their fields). Think of it as some kind of n × n mapping between objects and perspectives with a composite view (aka virtual object) in between. This is how we’re populating the timeline shown on the bottom part of this customer dashboard with emails, events, interactions, and tasks. The upper part if for mapping the fields of the virtual object to the fields of its sources. The middle part is for mapping the same fields to the dimensions of all the perspectives supported by the virtual object’s sources. And the bottom part shows all the records of the virtual object, optionally filtered by the views that are part of its definition (its sources). The middle part is automatically populated by default bindings that are calculated exactly the same way as default perspective bindings in the object view, and it’s collapsed by default in order to keep the user interface as simple as possible. The overall user interface is preceded by a simple wizard through which users can pick a target perspective and a set of sources. From there, the complex matrix shown above is automatically generated and pre-populated, but lets users add new fields to the virtual object that is being configured (hence the plus sign at the very top right). Clearly, this has to be the most complex part of our user interface, but it’s not entirely clear how it could be simplified, for what it does is intrinsically complex (n × n mapping between the fields of multiple objects and the dimensions of multiple perspectives). It’s actually quite amazing that the whole thing could even fit within a flat 2D metaphor…

If you can understand this mockup, consider yourself a robot. This is a draft for the upcoming Composite View Editor. What it does is pretty cool: you select a perspective (Timeline here) and a set of sources (objects or views), and it automatically creates an object model for a virtual object (aka Composite View), which is then mapped to the fields of sources (objects or views) and the dimensions of all the perspectives supported for the selected sources (based on the datatypes of their fields). Think of it as some kind of n × n mapping between objects and perspectives with a composite view (aka virtual object) in between. This is how we’re populating the timeline shown on the bottom part of this customer dashboard with emails, events, interactions, and tasks.

The upper part if for mapping the fields of the virtual object to the fields of its sources. The middle part is for mapping the same fields to the dimensions of all the perspectives supported by the virtual object’s sources. And the bottom part shows all the records of the virtual object, optionally filtered by the views that are part of its definition (its sources). The middle part is automatically populated by default bindings that are calculated exactly the same way as default perspective bindings in the object view, and it’s collapsed by default in order to keep the user interface as simple as possible.

The overall user interface is preceded by a simple wizard through which users can pick a target perspective and a set of sources. From there, the complex matrix shown above is automatically generated and pre-populated, but lets users add new fields to the virtual object that is being configured (hence the plus sign at the very top right).

Clearly, this has to be the most complex part of our user interface, but it’s not entirely clear how it could be simplified, for what it does is intrinsically complex (n × n mapping between the fields of multiple objects and the dimensions of multiple perspectives). It’s actually quite amazing that the whole thing could even fit within a flat 2D metaphor…

This mockup is a bit hard to understand, but the bottom part is what our next view editor will look like. We’ll essentially merge the grid perspective and the view editor. It’s a bit radical, but it should dramatically simplify the overall user experience.

This mockup is a bit hard to understand, but the bottom part is what our next view editor will look like. We’ll essentially merge the grid perspective and the view editor. It’s a bit radical, but it should dramatically simplify the overall user experience.

Dashboard

After months of procrastination, we’ve finally decided to start working on our dashboard framework. It will be built next week by Florian as part of the first Dojo session. It will let users create dashboards that can display any number of widgets, with a drag-and-drop user interface powered by the ultra-cool gridster.js. Users will be able to create their own dashboards, with multiple dashboards for each of the following levels:

  • Home
  • Application
  • Module
  • Object

Dashboards will be persisted using a new Dashboard object defined with the following fields:

  • Level (as defined above)
  • Container (a reference to an application, a module, or an object)
  • Definition (a JSON object)

In order to make it work from a user interface standpoint, we’ve also introduced the concept of home screen, which can display objects from multiple applications. This home screen will be customizable by users, and will be persisted in the user’s preferences.

Widgets will be embedded on dashboards using the concept of dashlets, defined as follows:

  • Name
  • Width (in span units, or full width)
  • Height (in span units)
  • Widget code (a snippet of HTML)

Fun stuff…