Looks like the Great Firewall or something like it is preventing you from completely loading www.skritter.com because it is hosted on Google App Engine, which is periodically blocked. Try instead our mirror:

legacy.skritter.cn

This might also be caused by an internet filter, such as SafeEyes. If you have such a filter installed, try adding appspot.com to the list of allowed domains.

iOS Skritter Terrible Problem (DEVS PLEASE READ)

Alexei   October 29th, 2012 7:15a.m.

Dear developers,

I used to always do my skrittering on my laptop, but now I have an iPhone and I've moved my skrittering there due to the better interface, there is, however, one huge problem.

In the PC version of skritter when you get a word you get pinyin and meaning WITHOUT the tone. That way you have to draw the character and that character's tone right after that. This allowed the student to engrave the tone in the memory along with the writing.

In the iOS, however, skritter gives you pinyin WITH the tone and you just have to write the character. I found that it made me much worse at remembering the tones. Please fix this.

Bohan   October 29th, 2012 8:30a.m.

try going to settings and select "hide reading"

russell359   October 29th, 2012 8:23p.m.

I agree with Alexei, I'd like tones presented on iOS the same way they are presented on the desktop (I'm getting a mini to be able to Skritter on the move).

Bohan, not sure whether hiding the reading would make the tones appear separately?

JieWen   October 29th, 2012 10:36p.m.

The only difference here is that the app doesn't ever lump writing/tone reviews into a single prompt. It will test you and see if you get a writing, and then in a separate prompt ask you about the tone. These two prompts will probably NOT be consecutive. Sort of an overreaction - lol

I hope you have "hide reading" turned on. If you don't, you aren't really learning much. Additionally, with "hide reading" turned on: if you look at the pinyin ever - then you should manually mark the card as wrong anyway, so this problem is irrelevant.

Tortue   October 30th, 2012 6:40a.m.

I don't think the problem is irrelevant at all, I also +1 Alexei

Alexei   October 30th, 2012 8:58a.m.

The problem is not about me reading it, as I do have the "hide reading" turned on.

The problem is that I learn a writing and a tone seperately, which decreases the effectiveness of my learning. As soon as I've started using the iOS version more often I got much worse at remembering the tones.

Why should we get the writing and meaning in 1 day, and the tone on the next day? It doesn't make sense. The tone should be inseperable with the word.

nick   October 30th, 2012 8:53p.m.

Glad to hear that you find the writing-plus-tone grouping useful on the web version. I spent about a zillion hours building that.

When I went to do the iOS client, I realized that it would save hundreds of hours of work to use a simpler code design where there's just one type of item per prompt. Even though it's more useful to do the prompt combining, it just wasn't worth it. (And we get to do a more interesting visual design this way, too.)

It isn't true that the writing and tone are inseparable on the web version, though. The two prompts are only combined if both are due. If you get the writing wrong and tone correct, you will often start to see the writing by itself, without the tone, for example.

If you want to keep the writing and tone always inseparable, then you can, on each writing prompt, both write the character and think of the tone, then mark yourself wrong if you got either part wrong. This will schedule the writing prompts to represent the atomic writing-plus-tone knowledge in the way that I think you're asking.

Alexei   October 31st, 2012 10:35a.m.

Can't you just group the writing and tone regardless of whether it's due or not? Or at least have that as an option.

nick   October 31st, 2012 12:37p.m.

On the web app, that wouldn't be a very hard hack to put in, but if not many people will use it, it doesn't warrant adding an extra preference.

On the iOS app, it's the architecture of having more than one item per prompt that can't be done simply.

nick   November 2nd, 2012 2:50p.m.

Extra preferences are very expensive in non-obvious ways. They make it harder for users to find the other preferences they need. They take up space in the UI. They necessitate maintenance and make it harder to add support for new platforms. They make it more difficult to track down problems, because you're multiplying the number of possible configurations. They require explaining.

If a preference isn't going to be useful to a large fraction of users, then we try to keep things simpler.

This forum is now read only. Please go to Skritter Discourse Forum instead to start a new conversation!