What's up タディちゃん
the Todd Rudick/Rikai.com blog
12/24/2004
A bit more detail on the new method for Japanese
... which is still just on the front page and text-results. External web-pages work, also with a new method, but I'll hold off a bit on that until I get more feedback.
Here's a summary of the differences:
Old method: I take html, parse it, segment (separate into words) the Japanese based on a complex algorithm, and place code for popups before returning it.
New method: I only add a little Javascript to the page. Then your browser parses the document little by little as you move the mouse around. When you go over a Japanese character, I grab the next 10 characters and send a message back to Rikai. Rikai returns the text definition which is placed into the popup.
Pros:
1 - The pages are tiny, and so I don't need to do any compression. Rikai has litle work to do and should respond much faster. People who can't use http compression can use the site again.
2 - I can afford to allow matching from any character, kana or kanji. So I leave it to you to parse the document, which generally you can do better anyway, plus it should be better for learning.
3 - I can afford much fancier popups, since the issue isn't bandwidth anymore but latency.
4 - Rikai becomes some neat javascript and a very simple script to return definitions. It should be very simple to clean up and distribute. Also I hope this can easily be turned into a mozilla plugin.
5 - As a side effect, I fixed some positioning and coloring bugs in Firefox. They're browser bugs actually, but I finally know what and worked around them. E.g., wikipedia finally looks right (though you can't see it yet).
6 - Better methods of managing wordlists, etc, using the keyboard. The old double-clicking thing still works though.
7 - I can show popups for most javascript generated content.
Cons:
1 - When you run your mouse over a character, you don't yet have the definition. There may be a short delay while you grab it from Rikai. So far it seems very fast.
2 - I'm unsure of the effect of having many many tiny requests. Hence I'm trying a different model where you have to hold down the "shift" key to see readings. One person didn't like this--I think it may be better for learners anyway, actually, since you're discouraged from looking up things you don't need. But maybe I'm rationalizing. Anyway, I plan to add a caps-lock binding to make it always-on. Please let me know what you think.
3 - The initial javascript is kinda slow in Internet Explorer.
4 - There's very little chance it'll work on browsers I don't have access to or don't otherwise care about. Right now I care about IE and Firefox. The old method works on Opera, Netscape 4.7, Safari (I hear), that KDE thingy, etc. On the other hand, hopefully others can fix the Javascript if they want support. IE on the mac, as always, is probably a lost cause.
5 - I guess I'm mostly playing--it's a huge change without much new functionality.
Here's a summary of the differences:
Old method: I take html, parse it, segment (separate into words) the Japanese based on a complex algorithm, and place code for popups before returning it.
New method: I only add a little Javascript to the page. Then your browser parses the document little by little as you move the mouse around. When you go over a Japanese character, I grab the next 10 characters and send a message back to Rikai. Rikai returns the text definition which is placed into the popup.
Pros:
1 - The pages are tiny, and so I don't need to do any compression. Rikai has litle work to do and should respond much faster. People who can't use http compression can use the site again.
2 - I can afford to allow matching from any character, kana or kanji. So I leave it to you to parse the document, which generally you can do better anyway, plus it should be better for learning.
3 - I can afford much fancier popups, since the issue isn't bandwidth anymore but latency.
4 - Rikai becomes some neat javascript and a very simple script to return definitions. It should be very simple to clean up and distribute. Also I hope this can easily be turned into a mozilla plugin.
5 - As a side effect, I fixed some positioning and coloring bugs in Firefox. They're browser bugs actually, but I finally know what and worked around them. E.g., wikipedia finally looks right (though you can't see it yet).
6 - Better methods of managing wordlists, etc, using the keyboard. The old double-clicking thing still works though.
7 - I can show popups for most javascript generated content.
Cons:
1 - When you run your mouse over a character, you don't yet have the definition. There may be a short delay while you grab it from Rikai. So far it seems very fast.
2 - I'm unsure of the effect of having many many tiny requests. Hence I'm trying a different model where you have to hold down the "shift" key to see readings. One person didn't like this--I think it may be better for learners anyway, actually, since you're discouraged from looking up things you don't need. But maybe I'm rationalizing. Anyway, I plan to add a caps-lock binding to make it always-on. Please let me know what you think.
3 - The initial javascript is kinda slow in Internet Explorer.
4 - There's very little chance it'll work on browsers I don't have access to or don't otherwise care about. Right now I care about IE and Firefox. The old method works on Opera, Netscape 4.7, Safari (I hear), that KDE thingy, etc. On the other hand, hopefully others can fix the Javascript if they want support. IE on the mac, as always, is probably a lost cause.
5 - I guess I'm mostly playing--it's a huge change without much new functionality.
Comments:
I think I like the new method you're experimenting with too. It's much better for studying, but for people who are new to the site, they may not really understand how it works.
Post a Comment
# posted by 
: 1:57 AM
: 1:57 AM