The Design System is the piece of The Grid that builds a webpage from page content.

A set of design systems are provided by The Grid. These use techiques like finite-domain constraint solvers, decision trees, content analysis, and polyrythmic pagination in order to produce a page which:

• Is content driven, reflects the particular items on the page

• Is visually pleasing, respecting the users site preferences

• Is effective at achieving the purpose set by the user

In the future, we intent to support “plugins” which can hook into and extend existing design systems. Such plugins could build sections for particular types of data, extend content analysis or heruristics, add or modify rhythms (scoring functions).

In the meantime the daring and ambitious may implement an full design system using the mechanism below.

API ¶

A design system is deployed as a .js file, and runs sandboxed in a browser using JsJob. On the server-side this is PhantomJS (with function.bind polyfill), on client-side it runs in a WebWorker (no access to DOM).

The design system must expose a polySolvePage function as an entry point.

window.polySolvePage = function (page, options, callback) { var html = “”; var err = null;

return callback(err, html, details);
};

The function will be called with a Page object containing the data to be put on the page. The page also includes the Site config for the particular page.

The callback should be called with the HTML page produced by the design system, or an Error object in case of failure. details may be an object with design-system specific information about the produced page or failure, for use in debugging and/or machine learning.

Assets in the produced HTML page must either be inlined in the HTML (recommended for CSS, GSS), or refer to a stable URL on a HTTPS enabled CDN (recommended for fonts, images).

Use custom design system ¶

You can configure a site to use a custom design system, by setting the style property to be a URL to .JS file implementing the API above.

style: https://example.net/path/mydesignsystem-0.1.0.js

It is heavily recommended that the JS is served over https. Also, we recommend that the path is strictly versioned, each new code change gets a new URL, and the configuration is updated to activate the new version.

Use config object of the PUT /site/$id API to change site configuration from an app. For example, using the configure-site example to enable a trivial design system.

thegrid-site-configure https://thegrid.ai/mysite style https://developer.thegrid.io/designsystems/original-html.js

Note: This will override the default design system completely! To reset back to the default design system, remove the style key/value.

Custom settings ¶

If your design system has settings, they should be persisted in the site config. You can use the API in order to build a web app with custom user interface to let users configuring settings.

For compatibility, it is recommended that all configuration keys are prefixed with your application/design-system name. For instance, if you have an option for ‘density’, use something like mysystem_density: 3.3 or use mysystem: { density: 3.3 }.

All changes to site configuration will trigger a rebuild of the pages on the site.

Running locally ¶

Assuming mypage.json is a page input datastructure, you can execute your designsystem locally using

thegrid-designsystem-run https://developer.thegrid.io/designsystems/original-html.js mypage.json > output.html

You can now open output.html in your browser.

You should have PhantomJS 2.x installed, and phantomjs should existing on PATH. This is then executed in the same way as on the production infrastructure.

Tools ¶

Designs systems are complex beasts. In order to create them we have built a set of libraries, services and tools. Several of these are already open source:

• Grid Style Sheets (GSS), constraint-based layout system

• imgflo, on-demand server-side image processing. Helpers: RIG and imgflo-url

• Grid Object Model (GOM), HTML templating and transformations

• finitedomain, High-performance finite domain solver

• Flowerflip, Promise-based finite-domain constraint solver

• Regimen, Chai.js-based expectations for item/block consumption

More to be released soon!

HTTP APIs ¶

Content-Type: application/json

Content-Type: application/json

Content-Type: application/json

Content-Type: application/json

Content-Type: application/json

Content-Type: text/html

Content-Type: text/plain

Content-Type: text/plain