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

What is that? The living proof that Florian Ribon is a punk.

How come? Well, for the past couple of days, we’ve been working on our widgets framework, but we’ve experienced some serious latency issues. At first, our user interface took 10s to load, which was positively not acceptable for widgets. Then, after a full day of work, Florian took it down to 3.5s, which seemed pretty good to him, but was still way too much.

Earlier today, I had a call with him and made it clear that we should not continue down that path, and that we should instead focus on pure HTML widgets for which all the processing would take place server-side. Of course, it would be a lot more work because brand new implementations of our perspectives and record view would have to be developed from scratch, but it was the only way to get down to 1s in my opinion.

After some discussions, Florian agreed with the plan, and I was fully expecting him to work on it tomorrow. But that was without taking into account the fact that Florian usually does not take no for an answer. Instead, he kept pounding, and as you can see on this screenshot, we’re now capable of displaying our Map perspective in 1,067ms.

Conclusion: I got punked, and I love it!

Widgets coming

Two years ago, we built a first version of our widgets framework. It had two issues:

  • Custom HTML syntax
  • Slow loading (because of our large meta-data cache)

Today, many customers need working widgets, and time has come for Florian to finally develop a brand-new implementation. First, we will use standard HTML 5 syntax using the data- attribute. Second, we will provide three styles of widgets:

  • iFrame with JavaScript
  • iFrame with plain HTML generated server-side by CircularJS
  • Direct JavaScript

For the two JavaScript versions, we will remove our meta-data cache entirely, which will make loading very fast. And for the HTML version, we will develop custom implementations of a handful of perspectives that really need a pure HTML rendering so that indexing can be done by search engines like Google:

  • Grid perspective
  • Tiles perspective

Similarly, we will build an HTML version of our record view, with two flavors: read-only and editable form, complemented by a JavaScript version that will provide all the features offered by the standard record view that is offered by our rich user interface.

For the HTML versions of our widgets, we will extend our UI Controls in order to support two rendering options: JavaScript and static HTML. The goal is to reuse most of the HTML that is used for them, and 100% of the CSS. This will make the maintenance of our large collection of controls a lot easier moving forward.

A first version of our widgets for all perspectives and for the record view will be available in both JavaScript flavors (iFrame and Direct) tomorrow. The HTML versions will come a little bit later, since we need to do all this refactoring of our UI Controls framework.

The second screenshot might not look like much, but it’s actually really cool. It shows our new Field widget, for the Workflow field of the Application record of the Object object. You can see that on the first screenshot, which shows a test page that we just added to test this new widget.
We actually added three pages, two of them being there just to better organize our tests and provide a nice URL for this first test page. The widget itself looks the way it does because it’s fully responsive and takes the whole width allocated to it. In a more realistic scenario, it would be nested within other HTML elements that would give it less real estate on the screen.
Now that our Content Management System (CMS) is really starting to work, we will build test pages for all our widgets and many other components of the platform. This will allow anyone to contribute to the testing and debugging of the platform and its components.
The second screenshot might not look like much, but it’s actually really cool. It shows our new Field widget, for the Workflow field of the Application record of the Object object. You can see that on the first screenshot, which shows a test page that we just added to test this new widget.
We actually added three pages, two of them being there just to better organize our tests and provide a nice URL for this first test page. The widget itself looks the way it does because it’s fully responsive and takes the whole width allocated to it. In a more realistic scenario, it would be nested within other HTML elements that would give it less real estate on the screen.
Now that our Content Management System (CMS) is really starting to work, we will build test pages for all our widgets and many other components of the platform. This will allow anyone to contribute to the testing and debugging of the platform and its components.

The second screenshot might not look like much, but it’s actually really cool. It shows our new Field widget, for the Workflow field of the Application record of the Object object. You can see that on the first screenshot, which shows a test page that we just added to test this new widget.

We actually added three pages, two of them being there just to better organize our tests and provide a nice URL for this first test page. The widget itself looks the way it does because it’s fully responsive and takes the whole width allocated to it. In a more realistic scenario, it would be nested within other HTML elements that would give it less real estate on the screen.

Now that our Content Management System (CMS) is really starting to work, we will build test pages for all our widgets and many other components of the platform. This will allow anyone to contribute to the testing and debugging of the platform and its components.

Field Widget

One of our customers needs to display the workflow state of records within their own user interface, and let end-users change this state directly from the user interface. In order to support this, we’ve decided to implement the Field widget, which was on a slightly longer-term roadmap. This widget will let you show a field of an object for a particular record, either in read-only mode, or in read/write mode. When used in read/write mode, it will display an optional Save button. And it will work for any field of any datatype, not just Workflow. We should have a first prototype ready by tomorrow.

Simplicity at play

Take a look at the list of JavaScript libraries on this page.

Up until now, I had to manually update this page every time we would add a new library to our arsenal (at least twice a week). And I would update this copy as well. Over the past few months, I must have wasted a couple of hours doing just that.

Now, take a look at this page.

To get the list of libraries, all I did was to type this:

<stoic-tiles object="stc_library">
  <li><a href="{{record.stc_website}}">{{record.stc_name}}</a></li>
</stoic-tiles>

That’s the power of STOIC widgets. Watch today’s webinar to learn more about them.

So simple, yet so powerful…

First widget in production

Now, something really, really cool. As indicated in our week #34 achievements, we’ve deployed our first widget on the stoic.com website. This widget is the map that you can see on our roadshow page. When loading it, give it a few seconds for all the pins to appear. And make sure to click on markers to get details about individual events.

To do this, we started by creating a new Roadshow application, with a single object called Meetup:

Then, we added a single HTML5 element on our roadshow page:

<object-map-widget
  id="map_canvas"
  stc-object="Stc_meetup"
  stc-geocode="stc_geocode"
  stc-name="stc_name"
  stc-date="stc_date"
  stc-website="stc_website">
</object-map-widget>

This gave us this:

Here is how it works: the line of HTML5 is dynamically parsed by AngularJS. From there, a custom directive calls our JavaScript API and fetches data about all our meetups, then populates it on a Google Map. Today, someone had to write that one line of HTML5 manually, but in a week or two it will be automatically generated by our View Editor.

How cool is that?

PS: If you’ve been paying attention, you must have noticed that all the dates on the map and in the user interface are off by a month, and our first six meetups scheduled for 2013 have a date showing as NaN/NaN/NaN. That’s because our very own Pascal forgot that getMonth in JavaScript returns an integer between 0 and 11 instead of 1 and 12. Granted, it makes no sense at all, but that’s what it is. So, contrary to what Pascal might wish, it’s a bug in his code, not just a design flaw in JavaScript. I surely hope he’ll fix it soon…

PPS: I have Pascal to thank for making the whole widget work in the first place…

PPPS: He still has to fix that bug though…

How to publish a spreadsheet on a website

And now something really cool: meet our upcoming sheet widget. This widget automatically turns a Google Spreadsheet into a dynamic HTML component. The way it works is pretty simple: you build a Google Spreadsheet with data, formulas, and formatting, then click on a menu item to generate one line of HTML. Then, you stick that one liner onto any web page, and an interactive copy of your spreadsheet is automatically added.

For example, here is what the original spreadsheet looks like:

And here is the resulting HTML page:

For a live example, go to our prize calculator at poetry.io.

The benefit of this approach compared to just publishing an entire sheet is that only certain cells are editable (in the example above, the Top Prize Amount), and the resulting HTML can be styled any way you want (here we’re using Twitter Bootstrap).

The way it’s implemented is pretty straightforward: when you want to turn your sheet into a widget, a bit of Google Apps Script code parses the sheet, looking for editable cells and for formula cells. Then, it generates a chunk of AngularJS code that is stored on a publicly-available file in Google Drive. It also generates one line of HTML that will fetch the content of this file whenever the page where it’s included is loaded by a client.

Of course, the approach has a few limitations. For example, not all Google spreadsheets functions are supported at this point, and some might not be implementable at all. But for most of them, we should be able to create JavaScript equivalents fairly easily.

This feature is still being developed at STOIC Labs, which is a secret laboratory staffed by François and myself. We’ll upgrade it to a real feature if we get the green light from the guys upstairs. Otherwise, we’ll put it up for bidding on Kickstarter after we ship our 1.0 release.