Closed scottgarner closed 11 years ago
Working backwards, I started with a simple setup to grab a Gist and feed it to Processing.js:
http://hoc.j38.net/display/#6950974
After adding a method to create a new Gist, the ability to share will pretty much be in place.
Fantastic to see you already have this test up and running!
I just pushed some new code with a cleaner architecture and very early support for creating new Gists.
I'm feeling slight pangs of guilt creating these anonymous Gists that I can't delete and that will just sit stagnant forever, but there doesn't seem to be anything I can do about that without requiring authentication of some kind.
A bigger question is exactly how the sharing should work. Can one just share at any time and basically have that sketch set in stone at the shared URL? There's support in the API for editing Gists and having multiple files in a single Gist, but that definitely would add a lot of complexity.
Here's the simplest interaction that I think might work:
1) User arrives at a result they're happy with. 2) They either click a single share button that presents them with multiple options (Facebook, Twitter, Email) or we have discrete buttons up front for each service. 3) The site silently creates a Gist, grabs its ID and generates a url to view it. Something like `http://hello.processing.org/display/#123456'. 4) We can either let the user edit the message that goes along with it, or just use a canned message: "Check out my first program at..." 5) User hits submit and it goes off into the world. 6) Vistors clicking the link are sent to the display page, which fetches the Gist and displays the sketch.
I think we should keep this dead simple and just provide an opportunity to share at the very end of the experience (the interaction you outlined sounds just right). This isn't a new platform for users to develop Processing sketches and share them, it's just a simple feature for the purposes of wrapping up the tutorial. One thing we might consider, however, is hitting a server side script to at least record a list of all the saved gists so we can track some overall stats about what people are making / sharing? But I think that statement adds something to our to do list and the more we can strip away and keep it simple the better.
I was hoping there'd be some easy way to tag them or something so they could be listed straight from GitHub. That doesn't seem to be the case. The only way I can see to form collection on that end is to make a fake account and store them all there.
Writing a little web service to collect this on Heroku would be trivial, so if there's time leftover that might be an option.
At a bare minimum, any links that are shared and clicked should show up in Google Analytics if it tracks fragment identifiers (#), which I think it can.
I think our approach is settled. I'll file additional issues as needed for specifics.
I'm all for using Gists for the share feature. I think we can easily do everything behind the scenes and have some kind of viewer page that takes a Gist id and displays it. Something like
http://hoc.processing.org/display/?id=7492857
.That probably precludes the creation of some kind of gallery page with all user work. It isn't something we've talked about, but I just wanted to point that out.
As for saving, I think we could definitely use Gists for that, too, though maybe some kind of cookie or local storage option makes more sense?