My name is Ismael Chang Ghalimi. I build the STOIC platform. I am a stoic, and this blog is my agora.
Wow! Check this out! Before and After… Earlier this morning, we received a suggestion from our good friend Sébastien to get rid of some of the unnecessary padding that was surrounding many parts of our user interface. We briefly discussed it among ourselves, then Florian decided to take a first crack at it. And while he was at it, he made a few improvements here and there to make our design a bit flatter. This is the result. I love it!
Great work Florian! And many thanks for your suggestion Sébastien!
Wow! Check this out! Before and After… Earlier this morning, we received a suggestion from our good friend Sébastien to get rid of some of the unnecessary padding that was surrounding many parts of our user interface. We briefly discussed it among ourselves, then Florian decided to take a first crack at it. And while he was at it, he made a few improvements here and there to make our design a bit flatter. This is the result. I love it!
Great work Florian! And many thanks for your suggestion Sébastien!

Wow! Check this out! Before and After… Earlier this morning, we received a suggestion from our good friend S├ębastien to get rid of some of the unnecessary padding that was surrounding many parts of our user interface. We briefly discussed it among ourselves, then Florian decided to take a first crack at it. And while he was at it, he made a few improvements here and there to make our design a bit flatter. This is the result. I love it!

Great work Florian! And many thanks for your suggestion S├ębastien!

UI refactoring

After we’re done with our MVP (sometime in September), we won’t add many new features. Instead, we’ll focus on making what we have work as well as possible. This will include making some serious refactoring of our user interface. This refactoring will not only apply at a technical level (to get rid of a single file that has over 20,000 lines of code now for example), but also and most importantly at a functional level.

From a functional standpoint, the primary goal will be to embrace a mobile first approach, driven by the packaging of our solutions. Whenever possible, refactored components will be built for smartphones first. But when a smartphone user interface is not applicable, we will optimize the development of our web user interace for tablets instead of desktops or laptops.

In other words, our device prioritization will be flipped 180 degrees.

We renamed the Social module to Collaboration and removed the Plus icon allowing a module to be added to the Platform application. There are two reasons for this: first, most users will never add a module to Platform; second, now that we’ve added the Gamification module, it allows us to display the twelve modules of Platform on a smaller 4x3 matrix of tiles.

The Relations section of the Info tab is now called Inbound Relations, and is collapsed by default. On this example, we’re showing all records of all objects that reference the Address datatype through a relationship, be it a simple or advanced one. For example, we can see that 8 fields are using this datatype. This is a perfect example of a feature that is made possible by using Elasticsearch as primary datastore, and would be virtually impossible to implement in a scalable fashion with a relational database.
The Relations section of the Info tab is now called Inbound Relations, and is collapsed by default. On this example, we’re showing all records of all objects that reference the Address datatype through a relationship, be it a simple or advanced one. For example, we can see that 8 fields are using this datatype. This is a perfect example of a feature that is made possible by using Elasticsearch as primary datastore, and would be virtually impossible to implement in a scalable fashion with a relational database.

The Relations section of the Info tab is now called Inbound Relations, and is collapsed by default. On this example, we’re showing all records of all objects that reference the Address datatype through a relationship, be it a simple or advanced one. For example, we can see that 8 fields are using this datatype. This is a perfect example of a feature that is made possible by using Elasticsearch as primary datastore, and would be virtually impossible to implement in a scalable fashion with a relational database.

We have restored the Relations section of the Info tab in the record view. This is allowing us to show all inbound relations that have a given record as target record. We will now refactor this section in order to show only inbound relations, since outbound relations are redundant with the relations displayed on the Main tab of the record view.

Check the menu bar on top of the charts at the top of the object view. It’s now fully responsive, showing less and less information as the object view gets more and more narrow. Before, the view name and record count would overlap on top of each other.
Check the menu bar on top of the charts at the top of the object view. It’s now fully responsive, showing less and less information as the object view gets more and more narrow. Before, the view name and record count would overlap on top of each other.

Check the menu bar on top of the charts at the top of the object view. It’s now fully responsive, showing less and less information as the object view gets more and more narrow. Before, the view name and record count would overlap on top of each other.

We streamlined the user interface for the creation of notes. What’s interesting about it is that it did not require any new code. Instead, all we had to do was to tweak our meta-data a little bit, by making the Notes field (Bootstrap field) of the Notes object important, and by providing a custom question for it, instead of relying on the canonical question.
For many other parts of the user interface that are really important, such as the Object Editor or the Field Editor, it won’t be that simple, and we’ve decided to develop ad hoc user interfaces for them, instead of trying to improve our canonical user interface. Canonical is great for these many scenarios that are not used very often, but ad hoc is far superior for the few scenarios that are used all the time. Let’s be pragmatic!
We streamlined the user interface for the creation of notes. What’s interesting about it is that it did not require any new code. Instead, all we had to do was to tweak our meta-data a little bit, by making the Notes field (Bootstrap field) of the Notes object important, and by providing a custom question for it, instead of relying on the canonical question.
For many other parts of the user interface that are really important, such as the Object Editor or the Field Editor, it won’t be that simple, and we’ve decided to develop ad hoc user interfaces for them, instead of trying to improve our canonical user interface. Canonical is great for these many scenarios that are not used very often, but ad hoc is far superior for the few scenarios that are used all the time. Let’s be pragmatic!
We streamlined the user interface for the creation of notes. What’s interesting about it is that it did not require any new code. Instead, all we had to do was to tweak our meta-data a little bit, by making the Notes field (Bootstrap field) of the Notes object important, and by providing a custom question for it, instead of relying on the canonical question.
For many other parts of the user interface that are really important, such as the Object Editor or the Field Editor, it won’t be that simple, and we’ve decided to develop ad hoc user interfaces for them, instead of trying to improve our canonical user interface. Canonical is great for these many scenarios that are not used very often, but ad hoc is far superior for the few scenarios that are used all the time. Let’s be pragmatic!

We streamlined the user interface for the creation of notes. What’s interesting about it is that it did not require any new code. Instead, all we had to do was to tweak our meta-data a little bit, by making the Notes field (Bootstrap field) of the Notes object important, and by providing a custom question for it, instead of relying on the canonical question.

For many other parts of the user interface that are really important, such as the Object Editor or the Field Editor, it won’t be that simple, and we’ve decided to develop ad hoc user interfaces for them, instead of trying to improve our canonical user interface. Canonical is great for these many scenarios that are not used very often, but ad hoc is far superior for the few scenarios that are used all the time. Let’s be pragmatic!

Florian refactored our CSS stylesheet for the display of participants at the top right of the default dashboard. This is fixing a bug that was showing the top of pictures that were not supposed to be displayed in the first place. Now, the participants dashlet should display properly on any screen size and resolution. Responsiveness is an endless endeavor…

Scalability of the user interface

Now that we have objects with over 100,000 records, it’s a lot easier to test the scalability of our user interface, because it’s breaking left and right, especially when using the grid perspective. There are a lot of parts of the user interface that worked really well with 1,000 records, somehow kept working with 10,000, but are starting to fall apart with 100,000. So we’ll go through them one by one, until the user interface is snappy all around. Then we’ll do the same for 1,000,000 records, then for 10,000,000, and so on, and so forth.