are there any plans for a public api?
shouldnt be too hard. would just require a common way of sending strokes to the server, prolly just the same way the flash plugin does now (or do the strokes get checked by the plugin itself???).

i'd really like to see a public api so i could develop my own native skritter client for linux.
that would also make development for mobile devices possible. i'd really like to see a native skritter client for my nexus one :), so if there would be an api i could maybe play around with it and write a testapp.

We've got one little bit done so far that can add words to your Skritter vocab. We will work on adding more stuff as time permits, so that more services can integrate with Skritter. (If people have specific API calls they want to make, let us know.)

I don't think we'll make a public API that will let third-party apps be fully compatible, though, or to download all the strokes in a character. We could work together privately on that for things that won't compete with Skritter, if they looked promising.

I wonder if you aren't underestimating the amount of work it would take to make even a minimally functional Skritter client or test app. We've actually let two other developers take a crack at it, hooking them up with sample code and everything. They were never seen again.

One of my biggest peeves is the current custom list system. I would love to see a public API that would let us create/edit/etc. custom lists. That would maybe allow third parties to build new ways to feed you vocabulary, which I would imagine would be in your interest.

Read access to our known words and their statistics would also be very useful. Then we could build third-party mashups that go beyond the current Progress page.

James

a third party client using a public api would by no means be a compitition.
bcs it woul still require the person to actually have a skritter account.

i am quite interested in the communication between the flash plugin and the server. are strokes checked within the plugin or on the server?

depending on how that is done it could be quite easy to develop third party apps

I would think that just because of network latency the strokes would *have* to be checked in the client.

James

that would make the whole thing a lot more complicated, since you would have to implement the same algorithms over and over again for each platform.
but yes, transferring every strokes start and end coordinates to the server may cause bad latencies.

I don't think it's just the start and end coordinates. Consider the differences between 丿and 亅.

James

iirc it works just like that... for example http://kiang.org/jordan/software/hanzilookup/hanzidict.html and http://jabtunes.com/notation/chinesestroke.html

I doubt it's just start and end. Consider the 4th stroke of 汤 .

I don't see how it can; there are many other examples. 冂 for example is two strokes; the second one starts at the upper left corner and ends at the lower right. That's quite different from a stroke like 乙 which starts and ends in the same place.

If you look at the jabtunes implementation it shows red lines, so it appears that it's finding a piecewise linear approximation of the stroke, not just where it starts and ends.

James

When I joined Skritter sent every stroke to the server to be analysed. It was very slow that way.

Making more Skritter clients is great. Making other software which just takes advantage of our whole character database would not be so great. So we can't totally open it up.

We actually still have the recognition algorithms implemented in Python on the server, so we could still make an API for that (it does require passing many points in the squig to the server). It took me about nine hours to translate it to ActionScript when we switched over. We could provide the recognition code under a confidentiality agreement if we someone needed it for another Skritter client, so that would make things easier.

I can imagine lots of good things happening from a Skritter API, but someone writing a whole practice client? It strains credulity. Does it look that easy?

well, what does a client need/do

- a way to communicate with the server (xmlrpc or whatever)
- authentication
- retrieve pinyin/definition from server
- input field: draw strokes, send points to server
- retrieve stroke result (correct/incorrect)
- display the result of the stroke and once its finished, the whole character
- retrieve next from server
and so on...

that'd be enough for a very basic client. most of the work here would be on the server side.

the other things could be made in a similar fashion.
for example the definition training.
- send character to client
- client displays character & "1-4"
- user clicks number
- client shows definition
- client sends clicked number to server

again the client would just be a tool to display the whole thing while the server does the actual work.

Ah. Because the client is much faster and more responsive than the server, some of the things you assume would be on the server are currently done in the client. But I see, if you wanted to make a very basic client, you could avoid a lot of the complexity. I think you'd need to add a bunch of it back before you'd get something you'd want to use, but I could be wrong.

an api like that could not cause competing products.
bcs the server is in control which char gets send to the client and when. the server is even in charge of the specific training method used for the next request.
that would allow third party clients with full functionality, without rewriting the same code for every platform again.
also some xmlrpc extensions can use TCP sockets instead of HTTP, which would reduce latency a lot in such a scenario.

think about it. i doubt you want to write all those embedded apps yourself iphone,android,symbian(urgh),
but those devices are perfectly fine for skritter, esp the newer generation ones. the touchscreens are really good.

I would be interested in working on a native Linux client (under NDA). I'd also be interested in making a proxy so that people could have a view-only web page of someone practising. My friends all tell me it's mesmerizing, and keep asking me if this is possible.

i'd be interested in that too, would use sdl and xmlrpc-c

Interesting. Are you guys on Google Wave? I like that for discussing these sorts of things. Add me and we can get into more details: livelily@googlewave.com

im not yet on google wave, can you invite me ? i do have a gmail account tho maci.stgn@gmail.com

George has sent you an invite (I'm out). Hope to see you on there soon.

I am on wave too and curious about your talk, so if you don't mind, add me to that wave. ID: shisoik@googlewave.com.

As you are talking about having mobile clients, you might want to check http://developer.openplug.com/ which could help some of you with cross platforms development.

This is a tools-centric strategy allowing “Write Once, Tweak for Any, Build for All”. You can read more (if interested by apps development on mobile) at this blog post: http://www.visionmobile.com/blog/2010/03/why-adobe-should-change-its-mobile-strategy-again/

Hope this helps some of you

PS: We will start thinking what APIs we would need to make ChineseTeachers.com an even better website to learn Chinese for Skritter Chinese learners (we do not do Japanese)

Decidedly less sexy, possibly, but I'd certainly like to pull out my progress indicators in an API. So I can import into an excel sheet, and look at how study time and breadth of vocab list impacts the learning rate - that sort of thing.

The obvious thing about having an API to add words etc... is that I some sort sort of glue could be possible by having, say, a flash card list import into Skritter from something like Pleco. That would pretty much rule.

You can probably already copy and paste your vocab between Skritter and Pleco. If not, let us know what format you've got and we'll see about it. And add me on Wave (livelily@googlewave.com) if you wanna get down and dirty with specific API calls you'd like.

Oh yeah I can alright, I did that with the text book word list I put into Skritter. I did need to do each section of the word list individually though (15 chapters).

I was talking about something potentially more immediate, like possibly even having Pleco place the HTTP calls to insert words from a particular word list. I don't know how interested Mike would be with that but we've already spoken about Pleco needing to be a bit better 'connected'.

I'll add you on wave.