The Scratch API 2.0 is a collaborative project that aims to build a friendly user interface to provide self-updating images and links for users of the Scratch Forums based on the ideas of the current API project.
The new update to the API has three main aims for improvement over the previous version.
1) Make images easier to create using an image building graphical user interface (GUI).
2) Make URLs to the images shorter and the images load faster.
3) Add a sharing element to the API so that users can remix others' signatures if they want to.
The website for the API is currently being developed at http://www.api2.comeze.com and we welcome your feedback. The site will hopefully be moved upon completion to a .scratchr domian though so don't get too attatched to any images you make while this project is in pre-release!
Version 1.4.2 which is the newest stable release of the project can be read about and used here.
Developers
Sparks
LS97
Fg123
We are currently not looking for more members of the development team as it gets harder to coordinate a development the more people are a part of it. Your feedback, suggestions and comments are more than welcome though!
Last edited by sparks (2012-08-23 09:53:14)
Offline
Here's a index of posts throughout the thread:
Element Attributes
Format of collapsable list box
More attributes
Nested elements
Verification method
Early interface mockup
Sitemap
Last edited by LS97 (2012-06-23 14:30:10)
Offline
I have ideas: most of them are to do with the actual programming of the functions, but here are the basic outlines of the features I dream of:
- Fully-working Javascript GUI where the user can add and move around objects to customise their API into a single image
- User system integrated with Scratch that allows you to save images for future customisation (this would also allow for us to save the details on a database instead of needing a URL to determine all the elements)
- Allow for more values to be found
Last edited by LS97 (2012-06-18 13:08:27)
Offline
I was the one that mentioned that security hole, right?
Offline
LS97 wrote:
I have ideas: most of them are to do with the actual programming of the functions, but here are the basic outlines of the features I dream of:
- Fully-working Javascript GUI where the user can add and move around objects to customise their API into a single image
- User system integrated with Scratch that allows you to save images for future customisation (this would also allow for us to save the details on a database instead of needing a URL to determine all the elements)
- Allow for more values to be found
I think this is exactly the sort of thing I was thinking! A javascript GUI should allow users to position elements around a space. Here's a few things that they could do:
add/remove elements (elements listed above the preview with (x) remove buttons next to them), move elements, change canvas size (perhaps set to the width of a sig space on the Scratch site). I think the biggest source of problems for us is probably going to be the bit where we try and make sure the PHP doesn't render differently to the preview!
I was also thinking that Scratchers should be able to log in with their account to see a list of their images, and save images they have created.
What do you mean by more value to be found? Like adding information about users and projects that currently don't exist such as post counts?
What are your thoughts on public skins, where a user can share their image with others who can browse through a collection for them? This would mean users could easily get hold of sigs with their project information in it if they wanted better graphics than they could produce themselves or weren't sure how to make their own?
Offline
Rendering the image identically in both JS and PHP will definitely pose some challenges. I'm thinking maybe a preview button could allow you to asynchronously fetch the PHP image to make sure it's good before applying it. Most of all though I'm worried that simple JS and HTML will not be able to handle the image creation in all browsers, but that's an issue we will have to live with.
For new features I do mean stuff along the lines of post count, but obviously not that exactly as with the new tiered system it will hardly change and users can easily update it themselves. And to be perfectly honest, that bullet point was just a filler to get three ideas in the post Nevertheless, I don't recall seeing stuff like "number of projects", "# of friends", "days registered", "random project", "2nd latest project" yet I can find a useful implementation of each in a cool sig.
Public skins sure are a nice idea, but I find them very restricting. Think about your signature right now; wouldn't that be also compromised by the tightening of security? I think a better option is to make sure we comply with Scratch's image standards (i.e. the same black- and whitelist system as the forums) and provide the images ourselves when possible. That said, sharing skins amongst users of the community can promote creativity and ultimately better skins, so having it as an extra feature would be great!
Sorry for the disorganised ideas in the post, 10:30 is too early for me
Offline
Interesting ideas! I think that you've mixed two of my ideas there with public skins: Skins that can be shared, and images that are approved and hosted with the API site before displaying. I think perhaps it /would/ be easier to pull the images from third-party hosts that are whitelisted. I'm a member of the Scratch assembla team now, so I may be able to push a small change to the current API that simply lists current hosts whitelisted with Scratch that we could pull up! Public skins is still an idea I like though - where designs can be shared and remixed by users if they wish.
That's true, there are still a lot of applications that haven't been added yet like you said! (Though 2nd newest project is possible atm by changing &num=1 to &num=2!).
How about we start mocking up ideas for the GUI, how we want people to manipulate the image will need quite a bit of work! 10:00 for me here and the sports day at the school down my street is very loud!
Offline
I'm sort of imagining the GUI with a few boxes. The first lists the elements in the image, the second shows the editable characteristics for the selected element and the third shows a javascript mockup of the final image. I can't think of a good name for an element that fetches data... maybe we should go with an "updating" prefix? "Updating Image", "Updating Text" and "Updating link".
================= Elements ======================
☐ Background
☐ Text-Box 1 (x)
☑ Updating Image 1 (x)
☐ Text-box 2 (x)
☐ Updating Text 1 (x)
=================================================
========= Updating Image 1 =======================
Type: [random] ☑ Scale
. Scale to width:[20] height: [20]
(x)Image 1: [link to image]
(x)Image 2: [link to image]
[+add image]
=================================================
I realise that we're going to have to make a list of all the elements that an image could contain, and all the changeable aspects that element could have, as well as how to best display that in the editor.
What if someone wants one set of random images if they are online and another set if they are offline? Is it worth doing that sort of nestability and how could it be achieved? Perhaps the online/offline element could be a box that can hold two seperate sets of elements?
Last edited by sparks (2012-06-19 07:48:29)
Offline
sparks wrote:
I think we need an actual name for the API too, rather than just Scratch API (Since there's technically another Scratch API ) Any thoughts anyone?
SUIL - self updating images and links
Scratch UpdatR
let me think of more, thats all i have so far...
Offline
sparks wrote:
I think we need an actual name for the API too, rather than just Scratch API (Since there's technically another Scratch API ) Any thoughts anyone?
MSRFSIP (MIT Scratch Random Forum Signature Image Picker)?
Offline
I like the idea of abbrevations. How about an adaptation of XenoK's "SUIL" to "SULI"? Easier to pronouce. Otherwise there are bound to be better ones!
DIAL: Dynamic images and links.
Last edited by sparks (2012-06-19 08:42:15)
Offline
SciTecCf wrote:
How about FIUA? (Forum Image Updater API)
The problem with FIUA and MSRFSIP is that they're not really pronounceable
Going in a completely different direction, how about "Forum Eye" or something?
Last edited by sparks (2012-06-19 08:44:52)
Offline
GlorImage -- a combination of glorious and image
Offline
XenoK wrote:
I like SULI self updating links and images.
EDIT: aren't these acronyms, not abbreviations?
If I remember correctly, an acronym is a series of letters that stand for something, but are pronounced as if they were an english word. An abbreviation is a series of letters that are spoken separately.
Acronym: BASIC, NASA, NATO.
Abbreviation: PHP, BRB, GTG...
Am I right?
Offline