From http://commonspace.wordpress.com/2013/04/25/webmakerv2/ "people can submit ‘makes’ made with any tool (e.g. Scratch). This second piece is essential if we want to open things up widely on the making as learning front: people don’t just want to make things with Popcorn and Thimble." The MakeAPI will have the infrastructure in place for this, but we currently have no plans that I know of for front-end submissions to it outside our tools. We need to know if this is June 15th or post-June 15, and if the former, we need to get the front-end piece designed and built. Assigning to Brett for decision.
I think we should do this, with the following experience: - user enters a URL - we try to grab OpenGraph data from that URL - we require that the user insert any missing, required OpenGraph data - we do something intelligent for thumbnailing if none is provided, OpenGraph style - we provide a description field where someone can explain what they did to "make" it
Part of me wonders if we shouldn't use Thimble to do what you're describing, embedding the thing you made in an iframe on the page. So in essence you make a quick thing around the thing you made, and it gets injected into the MakeAPI. I'm not sure if this is good or not...
The direction the MakeAPI is on right now will limit make creation to "trusted" tools only. Trusted tools being those that are given the credentials for basic authentication with the API. I think Post June 15th would be better for letting any app submit a make, unless we create a submission tool that creates the make on their behalf. Another possible solution could be API keys that we can hand out to apps that request them.
(In reply to David Humphrey (:humph) from comment #2) > Part of me wonders if we shouldn't use Thimble to do what you're describing, Given comment 3, I guess that's pretty much a requirement if we want it pre-June 15th although I'd want the template to be super-duper clear, I think. It wouldn't be a fantastic experience, regardless :(
Creating another app is pretty easy here, so we won't have to worry too much about that. I'll also note that what we're describing here would be a pretty tightly scoped mobile app, consider: * I make something, only requirement is that it lives at the other end of a URL. Maybe I made an amazing cake, and I've taken a picture, posting it on Flickr. * I go to the mobile app to share this Make with the world, and do essentially what Beltzner described above in a clean little UI tailored for this data entry. I click the "Made it!" button or something and close the app * Behind the scenes, that app talks to the MakeAPI and pushes a new entry for my Webmaker user for this awesome cake I made. MVP of this might be a single web page you hit that has a form for filling out this make-metainfo and dumping it into the MakeAPI. Bonus points for it being good in a mobile browser. Bonus bonus points for making that an app. Bonus Bonus Bonus points if you also make me that cake I described above.
Brett/Mark: We still need a hard decision made about what's in scope for June 15th here, and what's coming after. If we're going to build m.webmaker.org as a form to insert random makes into the MakeAPI, we need to get bugs on that asap.
I'd guess there are multiple stages to this including: 1. Spec and build a way for trusted sources / sources we issue a key to to publish to the Make API. 2. Find and deploy beta with test cases of sites that we want to have using the MakeAPI. E.g. Scratch, Meemo, Cheezburger, etc. 3. Revise and open up to other apps that want to publish to the API. My 2 cents on priorities: I'd say #1 is in scope for June 15 if it's easy and natural, but is a nice to have. That's Brett's call on resources. And that #2 is in scope for June to September and is probably driven by the content team. Almost certainly #3 is out of scope until the fall unless things go really swimmingly w/ the beta.
Mark: I actually think that's different from what we're talking about here. While we may wish to provide an endpoint that allows sites like Scratch to publish to the MakeAPI in order to put their content in our system, I don't think it's reasonable to expect many of them to make that a specific endpoint especially if they're already quite content in providing a publication service for their users (ie: quickmeme, cheezburger, etc) What I thought we were discussing here was enabling a use case where a user on webmaker.org was able to say "hey, I took a picture of this thing I made and put it on imgur or flickr or facebook or whatever" and have us go to the URI they indicate and extract a "make" out of it and put that data into our API resulting in a published object (that may just be a page with an iframe grabbing the relevant content). AIUI, the "that app" that humph refers to in comment 5 is a node.js app that we'd be building, not the service on which the user had already published the make.
Right, I think that Mark's use case is a second step after we solve this bug, which is about having a front-end way for our users to do self-serve additions to the MakeAPI, and therefore the galleries. If I make something with Scratch or Cheezeburger or whatever, and I have a URL, I can go to something like m.webmaker.org and I get a Twitter/Facebook like status box; but instead of saying what I'm doing, I say what I made: I just made [...............] [ OK ] They enter their URL, click the button, and we give them back a form to fill out some data. Hopefully we can fill a bunch of it out for them automagically (that's bug 868146), including things like a title, description, thumbnail, and other nice-to-haves for social sharing. Then we insert it into the MakeAPI for them, and it will appear along with things they make in Thimble/Popcorn Maker. Having this be a one-click activity from other sites to ours, like a G+ button from Google, is also a good idea, but needs a different bug. I also think it's not a June 15 blocker, since people aren't aware of us yet, so won't need it.
I'm closing this as MakeAPI has evolved - let's file more granular bugs for 3rd party publishing to Webmaker as they arise.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.