17 Oct 2020 by Forrest Oliphant
Meemoo lives!
This is how I started my last post (2016). I’m happy that Meemoo continues to work whenever I spin it up with an idea.
(Saving to gist needs some help. Github probably turned off anonymous Gist creation, or changed that API. Other than that, I think that this project is stable enough to keep working. As long as I pay for the domain registration.)
Meemoo as a project and thesis always had these layers in mind:
I commissioned this illustration to show how these layers would unfold:
With this sequence of layers in the Meemoo ecosystem, I imagined guiding folks down the rabbit hole towards “learning to code.”
There was also supposed to be a community site for sharing and forking these mini apps. Why did Meemoo stall with just the dataflow layer? Probably some combination of starting a family, running out of grant funding, and getting a day job. Standing up an online community is a major obligation in terms of moderation. I felt like making a community without committing the resources to make it a safe and good learning environment would be worse than not making the community at all. Meemoo hasn’t gained traction or a life of its own, which I’ve decided to be OK with.
Also it reached a local maxima of being “fun enough,” which isn’t a bad thing.
So what is there to do at this point? Will there be a Meemoo 2.0?
Meemoo is built on Backbone and jQuery/UI, which are fairly obsolete. On the other hand, they are simple, stable, and work.
A lot has changed in web development in the 9 years since my first commits. In the first version, the camera module was powered by Flash, because the web standards for accessing a device camera hadn’t shipped yet. As standards like this shipped to the web platform, I was able to remove code and complexity.
Meemoo’s “Hello World” app is a camera module that sends images to an image stack, that can compile an animated GIF.
If Meemoo modules were packaged as Web Components, it would be possible to build this app with a few lines of code in any web page:
<meemoo-cam id="cam" />
<meemoo-animation id="animation" />
<meemoo-link from="cam" out="image" to="animation" in="image" />
By taking the module code out of the dataflow environment, it might be possible to jump from interface to code more easily. The dataflow environment wouldn’t be needed to style or edit the app, but it could be loaded as a layer on top of (or under) the published app.
I’m not sure if Web Components are really the best abstraction for what I want to do here. There are at least 43 ways to build Web Components, that have tradoffs with authoring complexity and compatibility with other frameworks. This has caused some analysis paralysis on my part.
I’m also not sure if “reusing Meemoo components” should be my first design goal with future Meemoo work.
Several of my web developer peers express fondness for Flash, as it existed around 2002. I credit the combination of vector editing, timeline animation, and scripting with my initial love for creative coding. Are there any environments that combine separate modalities like this now? What about other metaphors, like spreadsheets for tabular data editing and visualization?
I’ve been thinking about designing a “thicker” Meemoo module with a full-featured animation timeline. Maybe also a mini spreadsheet module.
But is dataflow the correct metaphor to be coordinating these modalities?
Could it be that the “correct” metaphor is just a webpage, with any framework, or none at all?
Meemoo components announce their inports and outports: what type of data they expect as input, and output. This is something that most component systems lack, including React and standard Web Components.
This enables a few things:
Do any other component systems expose “data types” like this? Is there room for some kind of standard around this?
After several years on the backburner, I’d like to find Meemoo’s next step. Got ideas? 👉 Talk in issue #145