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

330 features

All features that were on our old wishlist have now been fully migrated to the new website. All 330 of them. As mentioned earlier, we could not really migrate the star ratings that have been used so far. Therefore, please take some time to go through our features, and upvote the questions (not the answers) for the features that you really like, especially the ones that are at the suggested and approved stages.

All features migrated

All features that were defined on our wishlist have been migrated to There are 286 of them at last count. Quite a few would deserve a lot more documentation, but we can easily add it over time, now that we have a proper framework for it.


Another great use case from Joe Geldart at Cloudreach, captured in this feature:

Andy, a Delivery Manager with FooCorp, is putting together a project plan for a contract his company is drawing up. All changes to his plan need to be approved explicitly by him, but he needs all his team to proof read the tasks and ensure he hasn’t missed anything of vital importance, or misrepresented the work to be done.

He decides to allow his team commenting rights on the ‘Task’ object. Andy first creates a project plan instance for his project from the template. He can then go into that app instance’s folder in Drive, choose the ‘Tasks’ object and share it with his team’s group with commenting permissions.

Members of his team can then view and add comments to records and the values of fields of records by going to the task object in that app instance. Conversation chains may be built up, including notifying particular team members of something relevant to them by using the Google+ +John Smith syntax in the comment. When an item is dealt with, it may be resolved in the standard way by pressing the ‘Resolve’ button.

By sharing this object with commenting, Andy is able to provide collaboration without losing his gatekeeper role for changes to records and values. He is also able to bring more people into the conversation with the very same user experience as they’re already familiar with from Google Docs, Google Spreadsheets, and Google Slides.”

This feature request could not come at a better time, because we’ve already added a Comments object to our platform, and the only thing missing is proper support for many-to-many relationships (aka N-N relationships, or multiple relationships). Currently, we only support the one-to-many kind, but many-to-many is very high on our priority list. So, as soon Pascal is done with real-time updates to our meta-data, I’ll make sure that he switches to that.

Thanks Joe!

Template applications

Earlier today, Joe Geldart from Cloudreach suggested to us an awesome feature:

"Peter is a scrum master at FooCorp. He has created a STOIC application for managing user stories called ‘Scrum backlog’. He wants to keep project data separated, so he chooses to publish the application as a template. He has been tasked with running the new Widget project at FooCorp. This project will use scrum, so he needs somewhere to store user stories for this project.

He goes to Drive, chooses ‘Application Template Instance’ from the create menu and chooses ‘Scrum backlog’ from the chooser page. After providing a name for the application, he is able to start adding stories to the backlog. All the objects, fields, views, etc. of the original are available in the Widget backlog. Any records in the original are also linked into the new instance, but records created in the copy are not available in the original or in any other copy. The Widget backlog can be organised into collections independently of any other instance. Peter can also share the Widget instance with just his team using Google Groups and Drive permissions. No other team will have access to the instance.

Peter discovers a bug with his backlog application to do with the join condition in one of the views. He updates the original, and is pleased to discover that all the backlogs people have created update at the same time. By using template applications, Peter can robustly organise and share structured information with his colleagues and allow them to make secure, private collections of information without Peter needing to see it.”

Now, this made my day! And trust me, I needed it, because our memory leaks killed my morning. So, when I received Joe’s email, I was ecstatic, for more than one reason. First, it’s the first time that we receive such a well-articulated request for feature, and I hope that it’s just one of many more to come. Second, it comes from someone who really does not need STOIC to build cool applications for the cloud, which means that we’re getting appealing to a broad spectrum of users, from non-technical to very technical. Third, it demonstrates that people who’ve never used STOIC actually understand what we’re trying to do, at a very fundamental level. So, I don’t know what we’ve done right, but it’s certainly working, and we need to do more of it.

Joe: thank you very much. Your feature is on our wishlist, including your picture!

PS: Please vote for this feature. It’s one of the best we could ever work on.

Spring Integration connector

One of the connectors we’re committed to building is one for Spring Integration. This will allow any service, protocol, and application supported by Spring Integration to be exposed as a set of STOIC objects, triggers, and actions (Cf. Agents). Because Spring Integration is an open source framework, it is very likely that we will also release our connector for it under an open source license (MIT License). Like most other connectors, We will fund its development through a dedicated Kickstarter campaign. If you’re interested, drop us a line!

More on connectors

We just finished the selection process of the very first native connectors we will try to build for the STOIC platform. Each connector will be developed through a dedicated Kickstarter campaign. Draft pages for a few Kickstarters will be released sometime next week.

  • Appcelerator
  • Basecamp
  • Box
  • Drupal
  • eBay
  • Eventbrite
  • Evernote
  • Facebook
  • FreshBooks
  • GitHub
  • Gmail
  • Google AdWords
  • Google Calendar Services
  • Google Contacts
  • Google Drive
  • Google Tasks
  • Google+
  • HootSuite
  • Kickstarter
  • LinkedIn
  • MailChimp
  • NetSuite
  • Parse
  • Pinterest
  • Pivotal Tracker
  • Shopify
  • Spotify
  • Spring
  • Stripe
  • TaskRabbit
  • Twilio
  • Twitter
  • WordPress
  • YouTube

Record rights management

Here is a very simple feature that could have significant implications and benefits for anyone using the STOIC platform: record rights management. In a nutshell, we’ve added a simple JSON field to every object called Copyright. In this field, we store the following content, for every single record of every single object:

  • License
  • Creator
  • Year
  • Sources

The license is a reference to a record of the Licenses object:


We pre-populated this object with all licenses defined by the Open Source Initiative and by Creative Commons, plus a handful like Copyright, Copyleft, and WTFPL. And because licenses are implemented as an object, you can add your own. We even included nice SVG logos for many of the most popular licenses. From there, we built a rather sophisticated form control allowing users to directly edit any component of a record’s copyright. For example, here is a record of the Country object (tidbit: my father comes from Algeria):


If you click on the Info tab, here is what you get:


This tells you that the content of this record is licensed under Creative Commons Attribution, was created by in 2012, and used ISO 3166-1 and Wikipedia as sources. If you wanted to change the license to another one, such as Copyright for example, all you have to do is pick the new one from the license selector:


Instantly, the license’s logo is refreshed (if available):


You can also edit the list of sources from there:


At first, all this might seem a bit overkill, but when you understand how STOIC works and how it turns everything into rather granular records, you realize that managing the rights of content developed with STOIC is actually quite important. And because STOIC will come with more and more pre-built datasets for things like Countries, Currencies, Languages, and Functions, you realize that properly managing the rights of applications that are mashing up the records of many other applications coming from a variety of places is of the utmost importance. This little Copyright field is the key to all that.

Workflow designer coming

It’s not quite ready yet, but I can’t resist sharing with you what it’s going to look like. After many months of research and experimentation, we finally found a way to properly represent workflows as a flowchart, on the fly. It still needs to be styled, but here is a first version:


While it does not look like much, it’s actually pretty ground-breaking. Here is how it works: the user defines a set of steps as a simple list, then adds optional transition rules through a simple selector (see screenshot below). While this is being done, the flowchart is instantly redrawn, with all the boxes and arrows neatly aligned and positioned in such a way that any potential for overlaps is minimized. The diagram is also scaled on the fly to fit within whatever real-estate is available on the flowchart’s screen area (responsive user interface).


We also take into account the colors of steps, from which a primary path can be derived:


Next week, I’ll send some more screenshots showing more complex processes and describing the rules we’re using to position shapes and draw arrows. In a future version, we will allow users to manually move shapes around in order to improve the diagram beyond what our little algorithm can do. This Workflow Designer is one of the projects that we’re considering to open source through a dedicated Kickstarter. If this is of interest to you, let us know!