My name is Ismael Chang Ghalimi. I build the STOIC platform. I am a stoic, and this blog is my agora.
Here is a nice one: images displayed on the grid in the first two screenshots (flags and logos) are shown without any visual treatment, while images displayed on the third (pictures) are rounded. This is because the former are illustrations, while the latter are photographies.
Here is a nice one: images displayed on the grid in the first two screenshots (flags and logos) are shown without any visual treatment, while images displayed on the third (pictures) are rounded. This is because the former are illustrations, while the latter are photographies.
Here is a nice one: images displayed on the grid in the first two screenshots (flags and logos) are shown without any visual treatment, while images displayed on the third (pictures) are rounded. This is because the former are illustrations, while the latter are photographies.

Here is a nice one: images displayed on the grid in the first two screenshots (flags and logos) are shown without any visual treatment, while images displayed on the third (pictures) are rounded. This is because the former are illustrations, while the latter are photographies.

With our refactored record view, we needed to refactor the way we display our workflow audit trail. Florian worked on this over the past couple of days, including some refactoring of the Workflow control when displayed in the Kanban and Tiles perspectives. Here is what he came up with, which is really slick in my opinion. Note how you can display the workflow audit trail by clicking on the icon displayed on the header of the workflow section within the record view.
With our refactored record view, we needed to refactor the way we display our workflow audit trail. Florian worked on this over the past couple of days, including some refactoring of the Workflow control when displayed in the Kanban and Tiles perspectives. Here is what he came up with, which is really slick in my opinion. Note how you can display the workflow audit trail by clicking on the icon displayed on the header of the workflow section within the record view.
With our refactored record view, we needed to refactor the way we display our workflow audit trail. Florian worked on this over the past couple of days, including some refactoring of the Workflow control when displayed in the Kanban and Tiles perspectives. Here is what he came up with, which is really slick in my opinion. Note how you can display the workflow audit trail by clicking on the icon displayed on the header of the workflow section within the record view.

With our refactored record view, we needed to refactor the way we display our workflow audit trail. Florian worked on this over the past couple of days, including some refactoring of the Workflow control when displayed in the Kanban and Tiles perspectives. Here is what he came up with, which is really slick in my opinion. Note how you can display the workflow audit trail by clicking on the icon displayed on the header of the workflow section within the record view.

We’ve dramatically simplified our refactored Info tab by reordering sections and collapsing the more technical ones like Identification, Connection, and Authorization. We’ve also added a few of our newer bootstrap fields there.
We’ve dramatically simplified our refactored Info tab by reordering sections and collapsing the more technical ones like Identification, Connection, and Authorization. We’ve also added a few of our newer bootstrap fields there.
We’ve dramatically simplified our refactored Info tab by reordering sections and collapsing the more technical ones like Identification, Connection, and Authorization. We’ve also added a few of our newer bootstrap fields there.
We’ve dramatically simplified our refactored Info tab by reordering sections and collapsing the more technical ones like Identification, Connection, and Authorization. We’ve also added a few of our newer bootstrap fields there.

We’ve dramatically simplified our refactored Info tab by reordering sections and collapsing the more technical ones like Identification, Connection, and Authorization. We’ve also added a few of our newer bootstrap fields there.

Before we refactored our record view, icons displayed under the record’s name gave you access to the record’s information, its workflow, and its relations. We’ve moved these somewhere else in order to make room for our contextual bootstrap icons. The three screenshots above show how to get access to the record’s infos, by clicking on the info icon next to the record’s description. Later today, we’ll do something similar for workflow and relations.
Before we refactored our record view, icons displayed under the record’s name gave you access to the record’s information, its workflow, and its relations. We’ve moved these somewhere else in order to make room for our contextual bootstrap icons. The three screenshots above show how to get access to the record’s infos, by clicking on the info icon next to the record’s description. Later today, we’ll do something similar for workflow and relations.
Before we refactored our record view, icons displayed under the record’s name gave you access to the record’s information, its workflow, and its relations. We’ve moved these somewhere else in order to make room for our contextual bootstrap icons. The three screenshots above show how to get access to the record’s infos, by clicking on the info icon next to the record’s description. Later today, we’ll do something similar for workflow and relations.

Before we refactored our record view, icons displayed under the record’s name gave you access to the record’s information, its workflow, and its relations. We’ve moved these somewhere else in order to make room for our contextual bootstrap icons. The three screenshots above show how to get access to the record’s infos, by clicking on the info icon next to the record’s description. Later today, we’ll do something similar for workflow and relations.

Look at the first screenshot. Did you notice anything? Yes indeed, the record view is much, much simpler than it used to be. Why? Because we removed all bootstrap fields from it. Why did we do that? Because they’re empty most of the time, hence totally useless. Unless they’re populated, in which case they become really important.
Our solution to this paradox? A new icon bar underneath the record’s name that allows you to add comments, attachments, notes, tags, and a few other things. When you click on an icon, it is automatically removed from the icon bar and its related form control is shown, like I did for adding a comment. And next time you open the same record, the icon is automatically removed from the list, and its related form control is displayed.
Why did we decide to remove icons from the bar? Because that way you know exactly what piece of content your record might be missing, by simply looking at the icons that are left. In other words, instead of always showing form controls that are empty, we show icons for form controls that are not there. Said another way, we hide what’s not there yet show that it’s not there.
That way, our record view is becoming highly contextual, which is awesome.
Everything is AWESOME!!!
Look at the first screenshot. Did you notice anything? Yes indeed, the record view is much, much simpler than it used to be. Why? Because we removed all bootstrap fields from it. Why did we do that? Because they’re empty most of the time, hence totally useless. Unless they’re populated, in which case they become really important.
Our solution to this paradox? A new icon bar underneath the record’s name that allows you to add comments, attachments, notes, tags, and a few other things. When you click on an icon, it is automatically removed from the icon bar and its related form control is shown, like I did for adding a comment. And next time you open the same record, the icon is automatically removed from the list, and its related form control is displayed.
Why did we decide to remove icons from the bar? Because that way you know exactly what piece of content your record might be missing, by simply looking at the icons that are left. In other words, instead of always showing form controls that are empty, we show icons for form controls that are not there. Said another way, we hide what’s not there yet show that it’s not there.
That way, our record view is becoming highly contextual, which is awesome.
Everything is AWESOME!!!
Look at the first screenshot. Did you notice anything? Yes indeed, the record view is much, much simpler than it used to be. Why? Because we removed all bootstrap fields from it. Why did we do that? Because they’re empty most of the time, hence totally useless. Unless they’re populated, in which case they become really important.
Our solution to this paradox? A new icon bar underneath the record’s name that allows you to add comments, attachments, notes, tags, and a few other things. When you click on an icon, it is automatically removed from the icon bar and its related form control is shown, like I did for adding a comment. And next time you open the same record, the icon is automatically removed from the list, and its related form control is displayed.
Why did we decide to remove icons from the bar? Because that way you know exactly what piece of content your record might be missing, by simply looking at the icons that are left. In other words, instead of always showing form controls that are empty, we show icons for form controls that are not there. Said another way, we hide what’s not there yet show that it’s not there.
That way, our record view is becoming highly contextual, which is awesome.
Everything is AWESOME!!!

Look at the first screenshot. Did you notice anything? Yes indeed, the record view is much, much simpler than it used to be. Why? Because we removed all bootstrap fields from it. Why did we do that? Because they’re empty most of the time, hence totally useless. Unless they’re populated, in which case they become really important.

Our solution to this paradox? A new icon bar underneath the record’s name that allows you to add comments, attachments, notes, tags, and a few other things. When you click on an icon, it is automatically removed from the icon bar and its related form control is shown, like I did for adding a comment. And next time you open the same record, the icon is automatically removed from the list, and its related form control is displayed.

Why did we decide to remove icons from the bar? Because that way you know exactly what piece of content your record might be missing, by simply looking at the icons that are left. In other words, instead of always showing form controls that are empty, we show icons for form controls that are not there. Said another way, we hide what’s not there yet show that it’s not there.

That way, our record view is becoming highly contextual, which is awesome.

Everything is AWESOME!!!

We now support the saving of transient views being created by users. Coming up with the right lifecycle for views was a bit tricky since we don’t have an edit mode anymore. Here is how it’s working now: when you manipulate an object from the object view, a transient view is created for this object in memory, but is not committed to the database until you click on the save button.
This save button is acceptable (Cf. Commit vs. Save) because clicking on it is fully optional. Essentially, your transient work will be lost if you don’t save it, which is exactly what you want, because most of the time you’re not creating a view, you’re just navigating through the records of an object, trying to find useful nuggets of information. But if you reach a point worth coming back to, all you have to do is click on the save button.
We now support the saving of transient views being created by users. Coming up with the right lifecycle for views was a bit tricky since we don’t have an edit mode anymore. Here is how it’s working now: when you manipulate an object from the object view, a transient view is created for this object in memory, but is not committed to the database until you click on the save button.
This save button is acceptable (Cf. Commit vs. Save) because clicking on it is fully optional. Essentially, your transient work will be lost if you don’t save it, which is exactly what you want, because most of the time you’re not creating a view, you’re just navigating through the records of an object, trying to find useful nuggets of information. But if you reach a point worth coming back to, all you have to do is click on the save button.

We now support the saving of transient views being created by users. Coming up with the right lifecycle for views was a bit tricky since we don’t have an edit mode anymore. Here is how it’s working now: when you manipulate an object from the object view, a transient view is created for this object in memory, but is not committed to the database until you click on the save button.

This save button is acceptable (Cf. Commit vs. Save) because clicking on it is fully optional. Essentially, your transient work will be lost if you don’t save it, which is exactly what you want, because most of the time you’re not creating a view, you’re just navigating through the records of an object, trying to find useful nuggets of information. But if you reach a point worth coming back to, all you have to do is click on the save button.

Our refactored object view is coming together really nicely, thanks to the heroic work of François and Florian. On the first screenshot, we have the menu shown when you click on a field’s header, allowing you to quickly configure the view in relation to the selected field.
Of course, you still have access to the advanced view editor by clicking on the caret shown on the left of the perspective icons. From there, you can graphically construct very sophisticated database queries by simply specifying filtering, sorting, grouping, and summarization rules.
This is fairly representative of the approach we’re taking for our entire user interface: expose the most useful features directly to the user, while hiding the more advanced ones behind menus or panels. That way, beginners do not get lost, but power users remain fully empored.
Our refactored object view is coming together really nicely, thanks to the heroic work of François and Florian. On the first screenshot, we have the menu shown when you click on a field’s header, allowing you to quickly configure the view in relation to the selected field.
Of course, you still have access to the advanced view editor by clicking on the caret shown on the left of the perspective icons. From there, you can graphically construct very sophisticated database queries by simply specifying filtering, sorting, grouping, and summarization rules.
This is fairly representative of the approach we’re taking for our entire user interface: expose the most useful features directly to the user, while hiding the more advanced ones behind menus or panels. That way, beginners do not get lost, but power users remain fully empored.

Our refactored object view is coming together really nicely, thanks to the heroic work of François and Florian. On the first screenshot, we have the menu shown when you click on a field’s header, allowing you to quickly configure the view in relation to the selected field.

Of course, you still have access to the advanced view editor by clicking on the caret shown on the left of the perspective icons. From there, you can graphically construct very sophisticated database queries by simply specifying filtering, sorting, grouping, and summarization rules.

This is fairly representative of the approach we’re taking for our entire user interface: expose the most useful features directly to the user, while hiding the more advanced ones behind menus or panels. That way, beginners do not get lost, but power users remain fully empored.

Wizards

A couple of weeks ago, Jacques-Alexandre showed us a prototype for a user interface that would make it a lot easier to create new applications, with a simple multi-step wizard. It came right at the time when I was giving some thoughts to the idea of a wizard-driven user interface for all our objects that could be used as a way to simplify the creation of new records. Some discussions ensued, and we agreed that it would be a good idea to implement it in order to dramatically simplify our overly sophisticated user interface.

The main goal is to simplify the creation of new records for any object, including objects themselves. The idea is to faciliate this creation by canonically generating multi-step wizards that would focus on an object’s required and important fields, with oversized forms. Such wizards would be stateful but non-persistent until the user would click on a Done button, allowing easy navigation through steps. And they would be defined using the exact same schema as the one used for screenflows, so that we could build a single graphical editor for both.

The canonical wizard would have three steps:

  • Required Fields, with Next and Done buttons.
  • Important Fields, with Previous, Next, and Done buttons.
  • Preview, with Previous and Done buttons.

The steps would be shown on a straight-through flowchart setting the user’s expectation about the number of steps involved in the creation of the record. The Important Fields and Preview are optional and would be prominently indicated as such, allowing the user to complete the record creation as soon as all required fields would have been populated. At any time, the user could also switch to the full record view in order ot populate any other fields that are neither required nor important.

Additionally, developers of objects could create custom wizards, much like they can create custom forms and views. This would allow the creation of records for more complex objects such as applications, objects, or purchase orders, for which many parameters must be entered, and for which many fields are relational, including advanced relationships for which multiple relations need to be instantiated.

Right now, we’re not sure whether we will include this in our MVP or not. More on this soon…

Here we go! Perspectives are now shown with icons. The two other menus will be gone by tomorrow, which will massively streamline the user interface for the Object View. And once we merge the Object View and the View Editor, it should be pretty slick…
Here we go! Perspectives are now shown with icons. The two other menus will be gone by tomorrow, which will massively streamline the user interface for the Object View. And once we merge the Object View and the View Editor, it should be pretty slick…
Here we go! Perspectives are now shown with icons. The two other menus will be gone by tomorrow, which will massively streamline the user interface for the Object View. And once we merge the Object View and the View Editor, it should be pretty slick…

Here we go! Perspectives are now shown with icons. The two other menus will be gone by tomorrow, which will massively streamline the user interface for the Object View. And once we merge the Object View and the View Editor, it should be pretty slick…

Simplify, simplify, simplify

Now that we’ve figured out how to create complex views and sophisticated charts, it’s time that we simplify our user interface so that all users could benefit from all this goodness, without having to fiddle through endless menus and cumbersome popups.

In such a context, Florian and I have decided to try something pretty radical: merging our grid perspective and our view editor, into a new grid perspective that would always display charts. The idea is that charts is another way to look at your data, hence our full collection of canonical charts could be considered as a perspective.

And because charts are intrinsically linked to the concept of views, and because views are best created when looking at data, either in raw form or through a pivot table, why not merging all three together? Raw data, view configuration, and charts, all tightly integrated together through the default grid perspective.

This approach would have the benefit of showing gorgeous charts immediately after importing any data (a spreadsheet usually), without having to click on any icon or menu item. And by doing so, we could refactor our grid perspective and get rid of its menus. Instead, we would just show the view’s name (All Records by default), and a set of icons, one for each perspective.

Down the road, we would apply the same principle to all other perspectives, showing different charts for different perspectives, according to the fields that are most relevant for a given perspective. For example, the Calendar perspective would show charts that have a chronological dimension, and the map perspective would show charts that have a locational dimension.

All the pieces are coming back together…