Demos Lab is an independent site about creative coding and interactive media art. This page explains how we write and test the sketches you see here, what you are free to do with our code, and how we credit the artists and works we write about. If something on the site falls short of what is described below, we want to hear about it.
How sketches are written
Every interactive example on Demos Lab is written to run directly in a web browser. You should not need to install anything, create an account or download a file to see a sketch working.
Most examples use standard web technologies: the Canvas API, WebGL, GLSL shaders, the Web Audio API, and established open-source libraries such as p5.js and Three.js. When a piece relies on a library, we name it in the text so you know what you are looking at before you read the code.
We aim for code that is easy to read and easy to change. That usually means:
- Clear variable names over clever shorthand
- Comments that explain the idea behind a step, not just what the line does
- Small, self-contained examples that demonstrate one technique well
- No hidden setup code that makes a sketch work on our pages but break when copied
If an example is simplified for teaching, we say so and point out what a production version would need.
How sketches are tested
Before a sketch goes live, we run it in current desktop versions of Chrome, Firefox and Safari, and check it on at least one phone. We look for a few specific things:
- It runs. No console errors, no blank canvas, no missing assets.
- It performs reasonably. Animations should hold a steady frame rate on ordinary hardware, not only on a powerful machine.
- It responds to input. Mouse, touch and keyboard interactions work where they are meant to.
- It resizes. The sketch adapts to different screen sizes without breaking the layout.
- It is safe to watch. We avoid rapid flashing, follow the widely used guideline of no more than three flashes per second, and add a clear warning when a piece involves intense strobing or flicker. Where practical, sketches respect the reduced-motion setting in your operating system.
Browsers change, and a sketch that worked last year can stop working after an update. When we find or are told about a broken example, we fix it or mark it clearly until we can.
Using our code in your own projects
Code examples published on Demos Lab are there to be used. You may copy them, change them and build them into your own projects, including personal, educational and commercial work. You do not need to ask permission first.
A mention of Demos Lab is welcome but not required.
There is one important exception. Some examples adapt or build on code written by other people. When that happens, we say so next to the example and name the original author and license. In those cases the original license applies, not ours, and it is your responsibility to follow its terms. The same goes for any library an example depends on: p5.js, Three.js and similar tools each have their own licenses.
Our written articles, illustrations and page design are not covered by this permission. Please do not republish our text as your own.
How we credit artists and works
Creative coding has a long history, and the people who built it deserve to be named properly. When we discuss a specific artwork, we credit it with the artist’s name, the title of the work and the year it was made. For example: Vera Molnár, (Des)Ordres, 1974.
Some further practices we follow:
- Uncertain dates are marked as uncertain. If a year is approximate, we write “c.” before it. If a work was developed over several years, we give the range.
- Collectives and studios are credited as they credit themselves. If a group publishes under a shared name, we use that name.
- Collaborators are named. Where a work had a programmer, composer or other contributor credited by the artist, we include them.
- Spellings follow the artist’s own usage. That includes names with diacritics and names written in more than one script.
- We describe artworks rather than reproduce them without permission. If we show an image or recording of someone else’s work, it is because we have permission or the work has been made available for that use.
Inspiration versus imitation
Many sketches on this site teach techniques that artists have used and made famous: generative grids, flow fields, particle systems, recursive geometry. Techniques belong to everyone. A particular artist’s style and body of work belong to that artist.
So we follow a firm rule. We never present a sketch as being by a living artist, as “a [name] piece”, or as a substitute for their work. We do not title our examples with a living artist’s name, and we do not make imitations designed to pass as theirs.
When an example is inspired by a technique closely associated with a specific artist, we say that openly, credit them, and explain how our example differs. The goal is to send you toward the original work, not to replace it.
How tools and versions are checked
Creative coding tools change quickly. A function that exists in one release of a library can be renamed or removed in the next, and tutorials that ignore this go stale fast.
When we write about a tool, we:
- Check the official documentation for the version we use
- State the library version an example was written against when it matters
- Load libraries at a fixed version, so a future update does not silently break an example
- Test that the code runs as written, rather than relying on memory or older tutorials
If we describe a feature that only exists in newer versions, or one that has been deprecated, we say so. When we revisit an older article and update its code, we note what changed.
Corrections
We will get things wrong sometimes: a wrong date, a misspelled name, a misattributed work, a broken sketch or an outdated function. When that happens, we fix it.
How we handle corrections:
- Errors of fact are corrected promptly. That includes names, dates, titles and attributions.
- Significant corrections are noted on the page. A short note at the end of the article explains what was changed and when.
- Minor fixes are made without a note. Typos, formatting and small wording improvements are simply corrected.
- Broken code is fixed or flagged. If we cannot repair an example right away, we mark it as not currently working.
Artists who believe their work has been miscredited or misrepresented on Demos Lab will have their concern taken seriously and reviewed first. If you spot an error of any kind, please contact us using the details provided on the site, tell us the page and what is wrong, and include a source if you have one.