Next Steps

[matthewepler]

Hi all,

I want to make sure the next steps in the ReCode Project address the issues you find most important. I'll outline my thoughts here and please feel free to respond.

The purpose of the project is two-fold:

1. Bring these original pieces back into public view
2. Make them accessible

Current Issues:

• No way for a translator to directly edit the code that appears on the site. it is currently stored as a string, and is not connected to the github file. This could be fixed by adding user sessions but I'm unsure if having that is necessary. The alternative to user sessions would be to put a hard link to the gitHub file once it's been merged. That link would pull the contents of the file every time the page is requested.
• Translations are not sorted by date.
• Links to filtered searches are not visible and therefore not copy/pasteable
• No biographical info on the original artists. No info on translators.

Moving Forward:

• There should be an easier way to submit translations and maintain how a translation looks without having to go through me.
• Would like to hear opinions on the advantages and issues with adding a way to see the code run in the browser (applets, .js, etc).
• I would like to continue to do translations in batches. Each collection will have its own issues and it will be easier to address them as a single project instead. People can suggest original content but ultimately it will need to be reviewed before it goes up on the site. I hope to have a new batch by the end of January.
• In 2013 I'd like to have a show of these works in New York. In preparation for that, I'd like to select exemplary works from the past and get in touch with the original artists. I would interview them about the work, get as much material as I could, and then pair them up with a contemporary coder who would work on the translation of that work. The two pieces and their code would be displayed side-by-side and both parties invited to the show. Ideally, we'd have two generations of coders in the same room talking to each other next to work that retains its original form as a product. This could be accompanied by a small publication, a series of talks, or any number of offshoots.

Thanks to everyone for their work and I look forward to making this as good as it deserves to be!

-Matt Epler

[lennyjpg]

Hi Mat,
I think the translations should run in a webbrowser. Love processing, but if it's not running in a browser people will only see images. That's great, but this is also where we started from.
I could rewrite mine and some others with paper.js for example. Or maybe processing can give me a .js or something. However, I'd invest some time to make this happen. This is a wonderful project and maximizing the audience that can see the code running seems relevant. Looking at the purpose you stated, online access should be a priority. Get the pieces running on as many devices as possible and your show is half done!

Editing the code on the site would be cool, but I feel like that's more of an extra.
( btw: I love how one can edit the source over here: http://paperjs.org/examples/smoothing/ )

Ideas for the show sound awesome, hope this happens.

+1 for running code in webbrowsers

[signalwerk]

Web

Go with Lenny:
+1 for running code in web-browsers

We would all benefit from running code in the webpage. I really like paper.js and I just started an other project with it. Paper's API is straight forward and is not doing the processingjs-java-emulation-foo. But processing.js is super easy to convert existing processing sketches. And of course with processing (Java) you've got the speed and endless possibilities. I think we should have a thought about the GUI of the sketch-interaction. Mouse-Interactions are easy but what about other parameters? Maybe something like http://workshop.chromeexperiments.com/examples/gui/ to keep the look and feel consistent. I don't suggest dat.GUI because I think it's not well maintained. It's more of an example. Someone knows a good lib like that?

Code

I suggest there are tree types of code preferred:

• paper.js
• processing.js
• processing

Trump rule

I suggest a set of trump rule to keep the code small:

• a processing.js sketch replaces an an existing processing sketch if visual equal
• a paper.js script replaces an existing processing or processing.js sketch if visual equal

[hughsk]

What about vanilla JavaScript + Canvas, or three.js? I've dabbled a bit with Processing but prefer those personally - some of the simpler projects could be easily pulled off without the need for a library, and having 3D translations running in-browser would be nice :)

[signalwerk]

well. js+canvas is ok. but I'd go for an abstraction layer. because it's not game design there is no need for 100% metal js speed. it's just smoother to have a lib to help. threejs is a bit 3d'isch for the translations on the current webpage.

[lennyjpg]

I think these pieces can have great value for education, so everyone sporting a different toolset would make things harder to read and understand for the people who would benefit the most doing so.
On the other hand, getting it to run in a browser with whatever means possible seems like far more important in the first place.

Other than that, consider the age of these pieces. What choice will make sure people can see that code run if another 40 years pass? Not sure about that. No idea what stack the original artists used, but rest assured that in a few decades ours will probably look just as obscure.

I agree with @signalwerk that performance is not a priority here. The future will hopefully be faster anyway.

[K0F]

I am afraid that nobody can predict 40 years of compatibility from now.. but I feel this is exactly what the project is all about.. there are mostly software art pieces with obsolete sources or without any source code archived at all.. the whole ReCode project is not just great idea for today's obsolete digital environments, but in many cases.. just imagine having at least some parts of source code from very early art pieces.. that would make the whole process of archiving and /or understanding of them much easier, even no matter what kind of super-exotic language it had been scripted in if there is any principle readable.

Probably we all know this, what I am trying to say is that storing the Knowledge (and considering the Art piece) as just rendered pictures or binary data in general, in era when it was possible much better way was just great mistake (it is surprisingly not so rare even today).

I think that it is not a question what kind of language to pick.. in general, the more mainstream it would be, the greater there is a probability of its readability in the future. For all the others just any source could be enough.

Of course the ideal variant is to keep a complete environment (preferably with its source code) /w digital art piece (preferably as source as well), able to compile and run on it, I think that is the only proper way to do this right.

[hughsk]

@signalwerk Yeah, I wasn't suggesting js+canvas for performance reasons but just because it could open the project up to more contributions without needing to impose another library/framework. Totally agree that consistency and legibility are important too, and paper.js looks like a nice choice. While the works in Computer Graphics & Art don't really depend on 3D, surely future projects will though?

Also happy to chip in with getting canvas/processing.js/paper.js/etc. translations running in-browser, if there's any way I can help out :)

[signalwerk]

@K0F completely agree. cood is anyway a good start.
Did a selftest: It took me now around 20 min to search for my first generative-client-work from 2003 (postscript). An other 2min to render and would maybe take 20min to bring it to processing.

@hughsk jupp. the 3D will come more and more. we will see what framework we will have in 5 year times... thanks to git we will track all the 23 framework changes we had to adopt the sketches for...

[lennyjpg]

So I rewrote one with paperjs.
Should I add it to where the .pde is? Delete the pde?
I guess I'll go with the rule as suggested by @signalwerk

[matthewepler]

Hi all. I'm back, and will be devoting a large amount of my time to the project for the next few months.

This is what I'm thinking for the in-browser question. To be relevant to a large number of students internationally, and simultaneously easy for experienced coders to jump in - I'm going to stick with Processing and Processing.js.

As I understand it, sketches can be stored on a server as one or multiple .pde files and called to the browser.

For a user to upload his/her sketch, they would fill out a form with basic info, and upload the .pde. In that form, they can specify (via boolean checkbox) if the sketch runs in JS mode and isn't using any 3rd party libraries that would prevent it from working in the browser. That boolean will determine which template gets rendered when the translation is viewed on the ReCode site.

I imagine the thumbnail images and .pde files will live in a bucket on Amazon S3.

I admit, however, that I'm pretty new to all this stuff and if there are any glaring mistakes in this logic please speak up.
Furthermore, I don't know ANY JavaScript (yet). So if you'd like to add any features using JS or have a better idea of how to integrate the sketches, controls, etc. Please also let me know.

For this and future decisions, I believe we will all benefit by sticking to the age-old motto: "Keep It Simple, Stupid," which is how this project was started. Yes, it could be fancier and have more options. Yes, it's limited in what languages it can support. But if it's simple and it works, then we can build on it later.

[matthewepler]

Okay y'all,

Major changes made today. Processing.js is now working. For each new translation uploaded, a .pde file is written to the app locally and called into a canvas element upon request. Some are not working. If you have contributed, please check your translations and if they're currently not running in the browser, try to update them so they can. Of course, if there's something you don't like or you believe is an error on my part please let me know.

I've added a filter option on the front page to see all the translations that run in the browser. Additionally, I've added a sentence to the description of every translation that specifies whether or not it will run in the browser as is, as well as basic instructions to how the interaction works for the pieces that are working as .js.

Other changes:

• new "Add Translation" button on every original artwork page allows users to upload their own. No more github necessary - anxious to hear your thoughts on that. I just don't see a need to stick with github. That being said, I have not made an edit page yet, and we need one. Can someone take that on so people can make changes to what they've posted? I'm thinking user logins are a hassle and a turn-off but if we can assign a key/hash to each work when it's posted and email it to the creator, that can serve as the key to access the edit page for a given translation. That will also give us a chance to capture contact info so we can reach out to people when we need to. Please contact me ASAP if you'd like to take a crack at this.
• every new Translation has a timestamp, allowing for chronological sorting.
• All thumbnails have been redone to eliminate the OS bar, drop shadow effect, and any "squishing" due to image ratio problems. The one problem there is that if the code doesn't run as .js, the cropped image becomes the default image, along with a note that states "Image shown is a cropped version of actual output," in the description for that Translation.
• All licenses have been changed to MIT license, and the site now has a license page (http://recodeproject/license). That means that we don't have to include the full wording of the license in every sketch.
• Newly uploaded images will live in an Amazon S3 bucket instead of locally in the app.

Things I need help with:

• Some of our URL's are currently not built to be specific enough to copy/paste as links. An example of this is the "/translationlist" path that is a consequence of using the drop-down filter on the homepage. The filter is working, but you can't use the URL to get back to a specific results list because the parameter isn't passed into the URL itself. I'm a little perplexed as to how to best approach this. Anyone have any ideas? Anyone willing to take a stab at it?
• We still have no way of getting people's contact info. I've been avoiding user accounts for good reasons, and I mentioned above the possibility of requiring an email to make a translation editable after it's been posted. Any ideas on this are welcome. This was a big problem when it came to making a decision on how to go about changing the license because I would have preferred to contact everyone personally and let them know what we were thinking and allowing them to opt out if they felt it necessary. With a contact list, this would be much easier. But, because we're not currently implementing user accounts, a repeat-translator would have to enter their email every time they make a new post. I'm stuck on solutions.

I'm sure more issues will pop-up as people begin to explore the new functionality. Please post them here so we can keep track.

Happy holidays to all!

Matt