My name is Ismael Chang Ghalimi. I build the STOIC platform. I am a stoic, and this blog is my agora.

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.

We’ve improved our grouping algorithms in the grid perspective. From now on, whenever we group on a categorical field (first screenshot), groups are automatically sorted by number of records, in descending order. And when we group on a workflow field (second screenshot), groups are sorted according to the critical path defined by workflows (fourth screenshot).
While doing this work, we’ve realized that sorting is actually very complex when we support multi-level grouping, because every grouping level might require a different set of sorting rules. Up until now, sorting was defined by one set of rules (sort by, then by, etc.). Now, our view generator supports the definition of one set of sorting rule per grouping level. The user interface of the view editor will be updated accordingly.
Unfortunately, this will make the view editor even more complex than it is already, and this might be the straw that brakes the camel’s back. Recently, Jacques-Alexandre has been suggesting that we develop a simpler wizards for facilitating the creation of views by new users. While I don’t like the idea of having two separate user interfaces for doing the very same thing, I must agree with the fact that our view editor, while extremely powerful, might be disconcerting at first. So we’ll have to seriously consider this option… Darn!
We’ve improved our grouping algorithms in the grid perspective. From now on, whenever we group on a categorical field (first screenshot), groups are automatically sorted by number of records, in descending order. And when we group on a workflow field (second screenshot), groups are sorted according to the critical path defined by workflows (fourth screenshot).
While doing this work, we’ve realized that sorting is actually very complex when we support multi-level grouping, because every grouping level might require a different set of sorting rules. Up until now, sorting was defined by one set of rules (sort by, then by, etc.). Now, our view generator supports the definition of one set of sorting rule per grouping level. The user interface of the view editor will be updated accordingly.
Unfortunately, this will make the view editor even more complex than it is already, and this might be the straw that brakes the camel’s back. Recently, Jacques-Alexandre has been suggesting that we develop a simpler wizards for facilitating the creation of views by new users. While I don’t like the idea of having two separate user interfaces for doing the very same thing, I must agree with the fact that our view editor, while extremely powerful, might be disconcerting at first. So we’ll have to seriously consider this option… Darn!
We’ve improved our grouping algorithms in the grid perspective. From now on, whenever we group on a categorical field (first screenshot), groups are automatically sorted by number of records, in descending order. And when we group on a workflow field (second screenshot), groups are sorted according to the critical path defined by workflows (fourth screenshot).
While doing this work, we’ve realized that sorting is actually very complex when we support multi-level grouping, because every grouping level might require a different set of sorting rules. Up until now, sorting was defined by one set of rules (sort by, then by, etc.). Now, our view generator supports the definition of one set of sorting rule per grouping level. The user interface of the view editor will be updated accordingly.
Unfortunately, this will make the view editor even more complex than it is already, and this might be the straw that brakes the camel’s back. Recently, Jacques-Alexandre has been suggesting that we develop a simpler wizards for facilitating the creation of views by new users. While I don’t like the idea of having two separate user interfaces for doing the very same thing, I must agree with the fact that our view editor, while extremely powerful, might be disconcerting at first. So we’ll have to seriously consider this option… Darn!

We’ve improved our grouping algorithms in the grid perspective. From now on, whenever we group on a categorical field (first screenshot), groups are automatically sorted by number of records, in descending order. And when we group on a workflow field (second screenshot), groups are sorted according to the critical path defined by workflows (fourth screenshot).

While doing this work, we’ve realized that sorting is actually very complex when we support multi-level grouping, because every grouping level might require a different set of sorting rules. Up until now, sorting was defined by one set of rules (sort by, then by, etc.). Now, our view generator supports the definition of one set of sorting rule per grouping level. The user interface of the view editor will be updated accordingly.

Unfortunately, this will make the view editor even more complex than it is already, and this might be the straw that brakes the camel’s back. Recently, Jacques-Alexandre has been suggesting that we develop a simpler wizards for facilitating the creation of views by new users. While I don’t like the idea of having two separate user interfaces for doing the very same thing, I must agree with the fact that our view editor, while extremely powerful, might be disconcerting at first. So we’ll have to seriously consider this option… Darn!