#118174 - bjoerngiesler - Sat Feb 10, 2007 8:26 pm
Hi,
I'm thinking of developing an efficient note-taking app for the DS to replace my pen-and-paper note taking in meetings. Advantages over dead trees: archivable, searchable, syncable. Disadvantage: Potentially MUCH slower, so slow, in fact, as to be impractical.
Therefore, I'm looking for the very fastest text input method. Cursive and even printed-character handwriting recognition is right out as it's VERY hard to develop and get right. What alternatives are there? I'm tending toward a QWERTY on-screen keyboard with a dictionary for word completion (like on the Wii). Has anyone tried alternatives such as Quickwriting? What are your experiences?
Thanks for sharing your opinions.
Regards,
Bj?rn
_________________
DSFTP homepage
#118177 - NeX - Sat Feb 10, 2007 9:06 pm
Well, I personally believe that using different button combinations for different letters would be fastest. It would just take some learning of the layout.
#118179 - dantheman - Sat Feb 10, 2007 9:31 pm
NeX, in that case you might want to try DanTE Advance. You press up/down/left/right/A/B to bring up a crosshair menu, and press up/down/left/right/A to select a letter, or B to cancel. L and R are used for special characters, while Select acts as Shift. Holding A while moving in a direction gives space, backspace, return, and delete. Holding B while moving in a direction moves the insertion point.
It's fast, but not quite fast enough for taking notes or anything.
In my mind, it would be fastest to just use the touchscreen and save whatever is drawn on it. Like I would write a letter or two and then hit a button to get a clean piece to continue working on. It would be very difficult to edit, yes, but for jotting down notes in real time, it might be the fastest method.
#118185 - Lick - Sat Feb 10, 2007 10:33 pm
QWERTY with dictionary sounds like the best you can get.
_________________
http://licklick.wordpress.com
#118186 - bjoerngiesler - Sat Feb 10, 2007 10:41 pm
| dantheman wrote: |
| In my mind, it would be fastest to just use the touchscreen and save whatever is drawn on it. Like I would write a letter or two and then hit a button to get a clean piece to continue working on. |
Something like this: http://software.brighthand.com/product.asp?id=1714? I agree -- however, it wouldn't be searchable, which eliminates one of the main advantages of doing this in the first place.
_________________
DSFTP homepage
#118209 - HyperHacker - Sun Feb 11, 2007 1:47 am
Someone mentioned a while ago the idea of an entirely button-based text input. You hold either A, B, X or Y and then press a direction on the D-pad. Since there are 8 possible directions times 4 buttons, this gives you 32 characters you can type this way. Toss in L and R as well and you have 8*6=48 possible characters. Add multiple buttons (e.g. hold A and B) and now it's 8^6=262,144 possible characters - enough to support probably every alphabet ever. (Though, it'd be "interesting" having to hold A+B+Y+R and press Up to type a letter. :-p)
Obviously we don't need a 262,144-character input method so we can cut that down a bit. Just A, B, X or Y and a D-pad button covers all of lowercase, space, and 5 punctuation characters. L and R can be used as shift keys to type uppercase, numbers and other punctuation. Properly optimized, this could be a very fast input method, allowing you to type most things by pressing only two buttons per character.
(Oh, and if you want to get ridiculous, you could have even more characters by varying the button order - hold A and press Left to get one character, hold Left and press A to get another. I really don't think we're ever going to need more than 262,144 characters in a DS notepad, however, you could use this for other tasks - Hold Left and press A to backspace, hold Left and press B to backspace a word, etc. Or, simply use the stylus to select text and perhaps drag it to a trash bin icon to delete it.)
If you don't want to go this route, look at TxtWriter. It's simply a QWERTY keyboard, but with button shortcuts - Up is Shift, Down is Enter, Left is Backspace, and Right is Space. (A/B/X/Y mirror this for lefties.) I use it all the time, and I can type damn fast with it. Of course, this may have something to do with me memorizing QWERTY and typing ridiculously fast even on a real keyboard. :-p You could, of course, add on to this by not making A/B/X/Y mirrors (simply provide a Flip option instead) - TxtWriter currently requires you to press the arrow keys on the keyboard to move the cursor, which is a pain.
_________________
I'm a PSP hacker now, but I still <3 DS.
#118213 - Lick - Sun Feb 11, 2007 2:02 am
You want to avoid HOLDING buttons. You want to avoid using any buttons at all, because DPADABXY can NEVER represent characters in a logical way. Don't sacrifice comfort and ease and cheap out on something really important nowadays: user-friendliness.
_________________
http://licklick.wordpress.com
#118215 - HyperHacker - Sun Feb 11, 2007 2:16 am
Ideally, the screen would tell you which buttons do what. Here is an example of what the screen might show when holding Y. This is unoptimized though; ideally, letters would be grouped together in some sort of logical order (e.g. most commonly used on A or B) rather than simply alphabetically. Eventually, you'd have this layout memorized, so you wouldn't even have to look at the screen.
_________________
I'm a PSP hacker now, but I still <3 DS.
#118217 - Mr. Picklesworth - Sun Feb 11, 2007 2:21 am
If it's just a notes writer, this is an idea I've been pondering. I probably won't do it for ages, so may as well throw it out for anyone else who has gone crazy to ponder.
There are really two kinds of text input:
One is the kind where the computer has to know what you have written, like with a programming language, text terminal or spell checker. The other kind is where the computer does not have to know what you have written; it just has to display it and store it.
Unfortunately, these two types of text input are constantly merged into one.
My hardly developed ponderings here are to suit that second kind of input: Assisted text drawing.
It's obvious why we can't just have an empty screen and say "Write your notes like you would on paper": it is different to handwrite on a touch screen, the DS's touch screen is too small to make handwriting remotely natural, the resulting notes page consumes a lot more space than plain text, letters end up being huge... the resulting page looks horrible. You may as well just use a sheet of paper.
So, what if it worked like a graphiti pad? I'm not talking character recognition, though; I'm talking character tidying. The input could feel exactly like a graphiti pad, where one draws a character in a big box and after the stylus is lifted for a while (or a button is pressed) the drawn character is cleaned up, sized down and placed as a letter lined up with all the others.
More fancy features could be popped in as well, for example the program could decide whether something is subscript, superscript, big, small, etc. based on how the letters were drawn onto the input box. (With a big letter being one that takes up most of the box).
The system would also well suit stuff like easy removal of text by striking through it (basic gesture recognition), moving of text (impossible with just drawing it on by hand, but completely possible here with each character being recognized independently!)...
Storage would be interesting. Each character could be sized down to a rather small size after being tidied, perhaps around 8x8 black or white pixels, thus consuming around 64 bits each, which is 8 times more than bits in a single 'regular' character.
The program could save characters to a font file of some sort so that a generated file doesn't take up any more than plain text. Then if an identical or very similar character has already been saved to the font file, a new one is not saved but rather the inputed character is linked to that old one. Processor usage could easily prove too much there, though, unless it was done while idling or saving.
That combined with an onscreen keyboard / Message-ease keypad for text that actually does need to be recognized by the program could work really well :)
It would take a lot of work to get such a thing to work (still have text cleanup to think of, which I can't begin to imagine), but I think it would be a really neat experiment!
_________________
Thanks!
MKDS Friend Code: 511165-679586
MP:H Friend Code: 2105 2377 6896
#118221 - zzo38computer - Sun Feb 11, 2007 5:03 am
| HyperHacker wrote: |
If you don't want to go this route, look at TxtWriter. It's simply a QWERTY keyboard, but with button shortcuts - Up is Shift, Down is Enter, Left is Backspace, and Right is Space. (A/B/X/Y mirror this for lefties.) I use it all the time, and I can type damn fast with it. Of course, this may have something to do with me memorizing QWERTY and typing ridiculously fast even on a real keyboard. :-p You could, of course, add on to this by not making A/B/X/Y mirrors (simply provide a Flip option instead) - TxtWriter currently requires you to press the arrow keys on the keyboard to move the cursor, which is a pain. |
Maybe, let's use the L button for some function as well? It can override the direction keys for some functions, such as move cursor.
| HyperHacker wrote: |
Ideally, the screen would tell you which buttons do what. Here is an example of what the screen might show when holding Y. This is unoptimized though; ideally, letters would be grouped together in some sort of logical order (e.g. most commonly used on A or B) rather than simply alphabetically. Eventually, you'd have this layout memorized, so you wouldn't even have to look at the screen.
|
Maybe you could do like Dungeon-Crawl, you hold down the direction keys that you want and then push A/B/X/Y while the directions are being hold down. You could use L/R buttons as well for some functions.
_________________
Important: Please send messages about FWNITRO to the public forum, not privately to me.
#118232 - Lick - Sun Feb 11, 2007 9:53 am
What about my just-thought-up "point prediction"?
[Images not permitted - Click here to view it]
- Four points that receive input, by SELECTION not by dragging through.
- Selecting same point twice cancels current letter.
- Requires at least 2 points before attempting prediction.
- Somehow it is intuitive because it resembles writing.
- You don't need to finish whole letter, you can select from the predicted letters.
I think instead of the four points, you could use 8-points that is:
_________________
http://licklick.wordpress.com
#118249 - Darkflame - Sun Feb 11, 2007 3:06 pm
I love Dasher:
http://www.inference.phy.cam.ac.uk/dasher/
I think it would work well with a stylus.
The key, however, is getting the right bias for the predicted next letter to be central and bigger. (eg, common letter groups, like "Q" would be almost certainly followed by U)
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#118253 - OOPMan - Sun Feb 11, 2007 3:51 pm
Bjorn, I did an implementation of QuikWriting for the DS a while back. You can get it here. It's a nice, light-weight implementation that doesn't rely on any other libraries, so all you need to do is feed it touch co-ords regularly and set-up the character tables...
On the implementation side, it wasn't too hard to get running but it is depedant a great deal on touch screen accuracy. Screen jumps can be rather irritating. There are ways of dealing with this problem, though...
Overall, I think don't think QW is a bad choice. Dasher is cute, but I suspect you'd find yourself cramped for space on the DS' screen and it's also possible that implementing it within the DS' resources could be painful.
Adding completion to QW is an idea, although I'm not sure how well it would work...
On the subject of on-screen QWERTY keyboards, they're a crappy solution, all things considered. A touchscreen is no replacement for a keyboard, and treating it as such doesn't work that well. Entering text quickly and accuratel for extended periods of time is an exercise in mental frustration and physical pain.
Another idea I had for a method of input on the DS was a kind of chord system using the buttons. Combining press combos of the D-Pad, ABXY-block and LR buttons would allow you to produce a wide range of characters and potentially one could produce output at high speed. However, such a system would entail a learning curve and implementation would have to be thoroughly thought out...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#118299 - Dood77 - Sun Feb 11, 2007 11:26 pm
Has anyone ever used DSerial to wire up their own PS/2 keyboard? Or better yet a PDA keyboard?
#118351 - Darkflame - Mon Feb 12, 2007 2:48 pm
If not Dasher, then I think a dasher-principled system could work on the DS.
That is, base it on stylus movement towards the letters.
Make the "most likely" next letter easiest/quickest to hit, and the rest dropping off in order of likelyness.
The method of the letters appearing, their placement, and style could be made to suit the DS screen and resources better then a mere port of dasher.
They dont need to move smoothly at all, for that mater they could just appear.
Purhapes you could just have a big central box, surrounded by smaller boxs (next likelys), those also surrounded by smaller boxs (the rest of the alphabeta)?
Effectively acting like a keyboard, only the positions of the keys change so that the most likely letter is always near the center, and the next likely letters surrounding.
The system could be made so that if the user press the middle letter, they can just hold down and drag to the next. (eg, "T>>H"). So that they can write two letters at once.
If they press any other letter, the letter they clicked goes on the screen, and the system guess's the next most likey letters.
The downside is the keyboard is totaly rearrangeing each time, so you dont get "letter memory" like a real keybord.
But imo, you dont get this on the DS really anyway, and the screen is small enough to see everything at once.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#118375 - Sweater Fish Deluxe - Mon Feb 12, 2007 10:12 pm
Well, you guys are coming up with some pretty complicated stuff that might be slightly faster. But there's a simple text input method used on a program for the GP32 that I found pretty quick.
You have three 9-square boxes containing letters and a blank space and fourth with punctuation. You select between the boxes with the L and R buttons. Without either shoulder button pressed the center box is toggled, hold L to toggle up the left box, hold R to toggle up the right box and hold both to toggle up the punctuation box. Pressing directions on the stick highlights the corresponding square of the currently toggled box or with no direction on the dpad pressed the center square is highlighted. Press A to "type" the letter of the currently highlighted square.
The extra step of having to press a button to actually type the letter obviously slows the process down over simply having the letter typed as soon as you highlight it with the dpad, but it has two advantages. First, dpads are not very exact and I suspect that you'd get a lot of mistyped letters if you relied solely on dpad input. Second, with this system the center square of the boxes can be used as well as the outside squares which means that you can get all 26 letters plus a space into just three boxes instead of needing four.
You can always make systems like these faster by arranging the letters so that, like a QWERTY keyboard, the most commonly used are the easiest to access, but that also dramatically increases the learning curve of using the system. In the system I described above, the center square of the center box (i.e. the square highlighted when no shoulder button or direction is pressed) is space, but otherwise everything is in alphabetical order. I'm not really sure that such a system would be fast enough for taking live notes, but then I'm not sure than any easy to learn system would be. It's the best system for inputting text using a controller that I've ever used, though, and also faster than a QWERTY keyboard on a touchscreen.
...word is bondage...
#118384 - HyperHacker - Tue Feb 13, 2007 12:09 am
Actually, QWERTY is designed to slow down your typing. It was invented back in the days of typewriters. Back then, more efficient layouts allowed people to type so fast they'd jam the mechanics, so QWERTY was standardized to force these people to slow down.
Well that's what I've heard, it could be BS for all I know. <_< I'd learn DVORAK but then I'd be in a pickle when I have to use other peoples' computers (like the one at work) and have to use QWERTY. One of those things that shouldn't be a standard, but is, like Ctrl+V being used for Paste and being right next to Ctrl+C for copy.
I wonder if an on-screen DVORAK keyboard would allow faster typing?
_________________
I'm a PSP hacker now, but I still <3 DS.
#118395 - tepples - Tue Feb 13, 2007 1:22 am
| HyperHacker wrote: |
| Actually, QWERTY is designed to slow down your typing. |
Myth.
QWERTY was designed as a compromise between the typewriter's original alphabetical layout (of which vestiges remain in the home row ASDFGHJKL) and alternation between left and right hands so that the type wouldn't jam. QWERTY was an improvement on ABC, but it was later discovered that QWERTY had serious problems ("monopoly", "sweater dress", etc), inspiring August Dvorak to invent the Dvorak Simplified Keyboard, which improved alternation and moved more commonly used English letters to the home row.
| Quote: |
| I wonder if an on-screen DVORAK keyboard would allow faster typing? |
Only with two styli. Dvorak's layout was designed for two independent hands. What we really need on the DS are the layouts used in one-finger keyboards. I'd recommend FITALY if that layout were not patented.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#118420 - OOPMan - Tue Feb 13, 2007 10:13 am
| Sweater Fish Deluxe wrote: |
Well, you guys are coming up with some pretty complicated stuff that might be slightly faster. But there's a simple text input method used on a program for the GP32 that I found pretty quick.
You have three 9-square boxes containing letters and a blank space and fourth with punctuation. You select between the boxes with the L and R buttons. Without either shoulder button pressed the center box is toggled, hold L to toggle up the left box, hold R to toggle up the right box and hold both to toggle up the punctuation box. Pressing directions on the stick highlights the corresponding square of the currently toggled box or with no direction on the dpad pressed the center square is highlighted. Press A to "type" the letter of the currently highlighted square.
The extra step of having to press a button to actually type the letter obviously slows the process down over simply having the letter typed as soon as you highlight it with the dpad, but it has two advantages. First, dpads are not very exact and I suspect that you'd get a lot of mistyped letters if you relied solely on dpad input. Second, with this system the center square of the boxes can be used as well as the outside squares which means that you can get all 26 letters plus a space into just three boxes instead of needing four.
You can always make systems like these faster by arranging the letters so that, like a QWERTY keyboard, the most commonly used are the easiest to access, but that also dramatically increases the learning curve of using the system. In the system I described above, the center square of the center box (i.e. the square highlighted when no shoulder button or direction is pressed) is space, but otherwise everything is in alphabetical order. I'm not really sure that such a system would be fast enough for taking live notes, but then I'm not sure than any easy to learn system would be. It's the best system for inputting text using a controller that I've ever used, though, and also faster than a QWERTY keyboard on a touchscreen.
...word is bondage... |
Conceptually that's actually kind of similar to QuikWriting, which also uses a 3x3 grid.
However, there are some problems with this idea WRT to the DS. We don't have an analog nub (I seem to recall the GP32/GP2X does?), so selecting diagonal directions would either be painful or inefficient...
It would be nice to see a Dasher implementation, but I personally wouldn't really use it. I grabbed Dasher after finding out about it and gave it a spin and it was fun to use, but it was also a little irritating. I ended up doing a lot of visual pan-and-scan-ing while using it, which was just a pain :-)
Ah, well, it's something to look into, for sure, but the Dasher source is pretty damn intimidating...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#118435 - JessTicular - Tue Feb 13, 2007 1:27 pm
I'm very surprised noone has mentioned an implimentation of the T9 algorithm.
The T9 algorithm is the one more commonly known as 'Predictive Text' on Mobile Phones.
It would be perfect for the DS - Hold it side-ways, put on the thumb strap, and start tapping away.
I've wanted to impliment this for quite some time now, but I can't find any decent information on it on the internet (nothing that makes any sense at least).
It's almost the perfect form of text-input for the DS, too. It has the touch screen the right size, two screens (one for text, the other for buttons), and the thumb strap to tap with. What more could you ask for?
Anyway, if anyone does impliment this, I would be interested to know about it :)
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org
#118443 - Lick - Tue Feb 13, 2007 2:31 pm
T9 License.. :(
_________________
http://licklick.wordpress.com
#118453 - arlow - Tue Feb 13, 2007 4:04 pm
So what characters would you need:
abcdefghijklmnopqrstuvwxyz 24
ABCDEFGHIJKLMNOPQRSTUVWXYZ 24
.,:;?!=+-%() 12
1234567890 10
Sums up to 70 characters
35 characters if you use caps
so you need space for 35 characters for basic notewriting (perhaps one wouldnt even use the symbols but ill just take em in there because this system might be useful for other homebrew too)
so you need the 35 characters spaces right
okay lets imagine we hold the DS sideways...we have access to the dpad, right? at least i can access it with my left hand thumb (i hold my ds with my left hand)...
so i can use the dpad at least in three directions its okay to left is a bit ugly
now lets think about how to use the screen if we imagine we take 12 characters a screen we have 3 screens... and if we now assign the directions of the dpad.... left switch screen up...down switch screen down...up activate caps one could even implement a caps lock via left or sumtin or the space would be on the left...(all directions viewed from DS sideways!!)
okay if take 12 chars a screen each char needs 64*64px space...seems enough for me...what do you say??
[Images not permitted - Click here to view it]
_________________
Hardware:
- 2 Nintendo DS (original V2; now FlashMe V6)
- 1 SuperPass 2
- 2 SuperCard SD + 1 * 2GB SanDisc miniSD + 1 * 3rdParty 512MB SD
(Could get together 7 DS + 7 SCSD)
Languages: English, German
#118461 - Lick - Tue Feb 13, 2007 5:48 pm
You don't have space and slashes (for urls)?
_________________
http://licklick.wordpress.com
#118463 - arlow - Tue Feb 13, 2007 6:19 pm
ok we might need a 4th screen :)
space could be on the left dpad
_________________
Hardware:
- 2 Nintendo DS (original V2; now FlashMe V6)
- 1 SuperPass 2
- 2 SuperCard SD + 1 * 2GB SanDisc miniSD + 1 * 3rdParty 512MB SD
(Could get together 7 DS + 7 SCSD)
Languages: English, German
#118468 - tepples - Tue Feb 13, 2007 7:37 pm
| JessTicular wrote: |
| I'm very surprised noone has mentioned an implimentation of the T9 algorithm. |
I could implement T9 or FITALY, but the program would freeze for a decade until the RTC returns a year on or after the patents' expiry.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#118480 - OOPMan - Tue Feb 13, 2007 9:22 pm
Hmmmm, my opinions on some of the newer ideas...
T9: As others have said, patented. Which doesn't mean you couldn't come up with your own algorithm, but you'd have to make sure it couldn't be linked to T9 in any form or fashion...
Vertical layout: Hmmmm, this isn't a deal breaker, if you ask me. It limits access to half of the buttons, which could be a bad thing, especially if you're doing a button-based solution. Even a touch solution loses out
Using fingers: For a start, DS Lites don't come with a thumb-strap, so that leaves a bunch of users high and dry. Even if they did, big fingers + small touch screen doesn't seem like a good combo to me for the kind of fairly detailed input necessary.
To be honest, despite doing a QuikWriting implementation, I'm dubious about the usefulness of the touch screen for extended periods of input. However the button options aren't great either.
I mean, one one hand we have the touch-screen. Sure, it's a touch-screen, but it's also small no matter how you rotate it and touch accuracy can be a problem sometimes. Ulimately entry is somewhat slow, even with fast solutions like QW, and prone to errors...
On the other hand we have the buttons. They're buttons, so they can be pressed quickly, but character input devices don't generally come in the form of a device with 2x4 sets of keys with an additional 2 shoulder keys and another 2 extra keys. In other words, a button-based solution, while no doubt faster than using the touch-screen, is likely to be horribly non-intuitive. Great if you're from Antares IV, but not so hot for us Earthlings...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#118487 - HyperHacker - Tue Feb 13, 2007 10:55 pm
I think touch screen solutions generally assume there won't be accuracy problems, because:
1) It's a software problem and can (if it isn't already) be fixed
2) It's kind of a given that accuracy problems will hurt anything that uses the touch screen.
_________________
I'm a PSP hacker now, but I still <3 DS.
#118511 - arlow - Wed Feb 14, 2007 12:55 am
perhaps the vertical isnt really needed (i just like the DS vertically so much :) )... with not holding it vertically you would even have more possibilities (L + complete DPAD) which would make it to 4 pages with caps via L!
for space one could implement hotkey eg press l + 3 times left or sumtin..
and then of course all the buttons on the horizontal with your stylus
and to the thing with the accuracy...i mean this has been a problem long around...someone should really start working on this if this still is such a greeeaat problem...(id even donate for it ...even though id love to see adhoc first :) )
to the thing with the buttons:
how would you implement it?? just a question to how you imagine it to be...
i could think of a solution like this:
R would be CAPS
L would switch the "pages"
dpad would select the line (perhaps highlight the certain line with the 4 chars on the lower screen) and then with the buttons you chose the letter
abcdefghijklmnopqrstuvwxyz 24
ABCDEFGHIJKLMNOPQRSTUVWXYZ 24
.,:;?!=+-%()/\ 14
1234567890 10
sums up to 72 chars
resulting in 36 needed fields
36/16 =2,25 so we would need about 3 pages with even more possibilities...
start could be space and select could be backspace or one could use the left space on the page
[Images not permitted - Click here to view it]
_________________
Hardware:
- 2 Nintendo DS (original V2; now FlashMe V6)
- 1 SuperPass 2
- 2 SuperCard SD + 1 * 2GB SanDisc miniSD + 1 * 3rdParty 512MB SD
(Could get together 7 DS + 7 SCSD)
Languages: English, German
#118524 - Darkflame - Wed Feb 14, 2007 2:07 am
Touchpad can simulate with resonable accuracy and quickness effectively much more inputs then button combinations. I cant believe any button based system would be as fast as a good touchscreen solution.
1 button press might be faster then a touchscreen, but not 4 or more! :p
The touchscreen is, after all, effectively just emulation of a greater number of buttons.
It seems obviously the way to go for any fast input method.
The question is more a balance between whats easy/reliable to tap and how much you can hit in one tap.
imo, a typical keyboard on the DS at the moment has each key far too small to be truely fast.
Thats why I thought a touchscreen method with a "falloff" of key sizes from mostly likely next letter to least likely would make sense.
Touchscreen has the added bonus of being able to write two or more letters at once...in theory.
Its much harder to code, however, then any mere button based system.
Any accuracy problems would be factored into the system.
However....err....what accuracy problems?
I have seen plenty of homebrew now that seems to get it spot-on.
Also...whats all the fuss over T9?
They couldnt have patented the idea of predictive text, only their own implimentation.
I dont think it would be that hard to code, not in the great scheme of things.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#118527 - tepples - Wed Feb 14, 2007 2:31 am
| Darkflame wrote: |
Also...whats all the fuss over T9?
They couldnt have patented the idea of predictive text |
You'd be surprised.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#118528 - Sweater Fish Deluxe - Wed Feb 14, 2007 2:35 am
| arlow wrote: |
| and to the thing with the accuracy...i mean this has been a problem long around...someone should really start working on this if this still is such a greeeaat problem...(id even donate for it ...even though id love to see adhoc first :) ) |
You mean the problem of stylus jumping when you touch the screen lightly? That *HAS* been fixed, but for some reason no one has incorporated the fix either directly into libnds or as a separate lib.
Do a search for posts by the user PadrinatoR. The guy reversed Nintendo's touchscreen code and fixed the jumping problem. I compiled several things with his fixes and can confirm that the touchscreen worked perfectly. Everyone else also had the same excellent results.
I was actually under the impression that his changes had been incorporated into the most recent version of libnds and PAlib, but your post made me check and I see that they haven't. I'm not sure I would have updated if I had known that the touchscreen problems are still not fixed in the "official" libraries.
Some people didn't like the way PadrinatoR released his code as altered versions of PAlib and libnds rather than as a separate library. Maybe that's why it's been ignored, which would be a damn shame since the touchscreen jumping problem is probably the biggest (or at least most obvious) bug in the homebrew libraries. It's a problem that keeps DS homebrew releases from being as professional as they might otherwise be. In fact, it just plain ruins a few games.
Since Wintermute and Mollusk or other people contributing to their libraries don't seem to be interested in incorporating PadrinatoR's changes, someone really ought to take up the code and release a separate library with working touchscreen functions. I don't know how exactly to do something like that myself, but if no one else does it, I guess I'll have to. It can't be too hard.
...word is bondage...
#118530 - Darkflame - Wed Feb 14, 2007 2:43 am
well, in that case we will use the idea of "anticipated letters", which is completely different :p
For what its worth, heres a quick doodle of my idea;
www.darkflame.co.uk/temppics/example.jpg
So, too write "THE" you would drag from the T to the H, and it would write "TH".
After the release of the stylus the system should spot "TH" has been entered, and change the keyboard so E is in the center (as thats the next most likely letter).
Then you'd just hit the E.
If, instead, I wanted to write "THOMAS", then Id drag from the T to the H, then click the O, then maybe drag from the M to the A (if it correctly guessed M), then click the S.
After each stylus lift the letters would rearrange.
Given the fact theres 12 central letters, as long as the system was fairly good at guessing the next letter, you would often be able to write 2 letters at once.
Even if the system wasn't so good at guessing, you still would have the more likely letters in the central squares, thus being quicker and easier to hit.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#118531 - tepples - Wed Feb 14, 2007 2:48 am
| Darkflame wrote: |
| After each stylus lift the letters would rearrange. |
So you'd have to hunt and peck every other letter. That could get complicated.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#118569 - OOPMan - Wed Feb 14, 2007 9:39 am
The touchscreen jumping bug is a real pain. It plays merry hell with my QuikWriting library, that's for sure. Usually input's okay, but every now and then you get a scattered co-ord and it complete screws up the word you're inputting. It would be nice if some would work Padrinator's work into a separate library or something. Did he provide sources to his mods of libNDS?
With regards to button-based solutions and speed and did some thinking about it a while back. I worked out that you could implement a fairly complete combo system using the buttons that wouldn't require a huge number of presses either. To start of with, you have, basically, 2 D-Pads (Normal and the ABXY block). The total number of 2-key combos on that is basically 32 (16 start with the left-pad and end on the right, the other 16 start right and end left). If you decided to use the L/R keys to flip character pagesets then you'd probably be able to access any char with a maximum of 3 button presses (Assuming that you decide to use 3 pages only [96 chars total] and wrap around, that is). The problem is, though, that it remains pretty non-intuitive. While it would probably be faster than touch-input for an experienced user, getting to that level of expertise would require a lot of acclimatisation. Even with a good predicitive text system, it would still be hard work.
On a side note, some people have been mentioning caps in the button context. Having a distinct button for caps is probably not as important as you might think, in this context, if you implement one aspect of a predictive text system, said aspect being predictive capitalisation based on punctuation. This would be pretty easy to implement and I have my doubts as to whether it could ever be legally problematic (In other words, we have a rule: After a full stop, the next char is caps. This is more a part of how english is written than anything else, so I doubt the T9 license holder could slap your wrist wrt to it...)
With regards to on-screen keyboards, I just don't see how tricks like fall-off key size could be anything more than a gimmick. The simple fact is a touch-screen is a not a keyboard and hence any kind of on-screen keyboard is not going to be fun to use.
The idea behind QuikWriting and Dasher is probably more important that any implementations. The basic idea behind it is this: Lifting the stylus is BAD! It slows down input. Hence, whatever system anyone is thinking of designing that uses the touch-screen should keep this in mind. Which is why on-screen keyboards will always be a sucky solution, because they ignore this. It's also the reason why Opera DS's hand-writing recognition system is bloody irritating (Besides it mis-identifying input).
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#118581 - Lick - Wed Feb 14, 2007 11:28 am
#118588 - arlow - Wed Feb 14, 2007 1:11 pm
QuickWrite implementation is okay!
But Dasher...ive tried it in JAVA and it does not seem quite fast to me!
_________________
Hardware:
- 2 Nintendo DS (original V2; now FlashMe V6)
- 1 SuperPass 2
- 2 SuperCard SD + 1 * 2GB SanDisc miniSD + 1 * 3rdParty 512MB SD
(Could get together 7 DS + 7 SCSD)
Languages: English, German
#118591 - OOPMan - Wed Feb 14, 2007 1:39 pm
I think Dasher is customisable. I've tested the windows version and it seems speed enough, I just don't like the interface...
Hehehe, also, I can see friends of mine who suffer from motion sickness not enjoying it at all...
A slight edit to what I wrote above...
I made a minor thought error when musing about button comboe system.
A button chain system using 2-press sequences to output chars with a total of 3 character pages (Switchable using presses of L&R) would allow for a maximum total of 196 unique outputs, more than enough for most character entry needs. Each page would consist of 64 characters accessed by 2-press sequences made via the 2 D-Pad blocks.
The general form of button presses can be divided into 4 groups:
1st press left d-pad, 2nd press right d-pad
1st press left d-pad, 2nd press left d-pad
1st press right d-pad, 2nd press left d-pad
1st press right d-pad, 2nd press right d-pad
This gives you an optimal number of characters per page, but on the downside in beans that Up+X is not equal to X+Up.
Actually, I'm liking this idea...I think I may whip up a test implementation over the next few days (Hehehe, nothing better to do at the moment, which is nice :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#118599 - Darkflame - Wed Feb 14, 2007 3:00 pm
| tepples wrote: |
| Darkflame wrote: | | After each stylus lift the letters would rearrange. |
So you'd have to hunt and peck every other letter. That could get complicated. |
I dont think we have letter memory at all on the current keyboard anyway.
With proper keyboards my figures no where everything is, with DS keyboards we have to look at what we are tapping.
From my expirence, that is.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#118618 - tepples - Wed Feb 14, 2007 6:33 pm
| Darkflame wrote: |
| tepples wrote: | | So you'd have to hunt and peck every other letter. That could get complicated. |
I dont think we have letter memory at all on the current keyboard anyway. |
No, but I know Q is always on the left side of QWERTY and P is always on the right side. Muscle memory gets me to within a key of my destination, and then I correct just before a tap.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#118624 - wintermute - Wed Feb 14, 2007 9:48 pm
| Sweater Fish Deluxe wrote: |
I was actually under the impression that his changes had been incorporated into the most recent version of libnds and PAlib, but your post made me check and I see that they haven't. I'm not sure I would have updated if I had known that the touchscreen problems are still not fixed in the "official" libraries.
|
What gives you that idea?
Padrinators code has indeed been incorporated in the latest libnds with some unnecessary cruft removed.
There are some other tweaks that I plan to make in order to improve things still further. I'm currently getting quite mixed feedback on the latest code, some people claim it's more accurate, others say the previous code was more accurate. Some are experiencing more jitter than others.
All in all it's a very difficult balance to get right and most of the developers seem to have been blessed with decent touchscreens for some reason.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#118627 - Sweater Fish Deluxe - Wed Feb 14, 2007 11:22 pm
| wintermute wrote: |
| What gives you that idea? |
Well, I noticed that /arm7/touch.h and /arm9/input.h hadn't been updated since sometime in 2005 and I thought PadrinatoR's changes had involved those.
Glad to hear that his code is incorporated afterall, though I'm surprised that it has varying success, especially that some people find it to be actually worse than it used to be. Stuff I compiled with his versions of libnds and PAlib seemed perfect pretty much. Maybe it is just down to individual touchscreens, though my screen sure jumped a whole lot with the old code.
...word is bondage...
#118642 - HyperHacker - Thu Feb 15, 2007 1:51 am
I was thinking about this at work... a plain old QWERTY touch keyboard seems to work fine for me, except it's slow because the keys are so damn small. So the obvious solution: bigger keys.
My idea was to divide the screen into twelve keys, and you'd use the buttons to cycle through them. However, when I drew it on paper (a 7x5.25cm box, the size of the DS screen) I noticed those squares ended up being very big, and I knew already that having only 12 keys on the screen would kinda suck. So I thought about it a bit, and came up with a solution: Split each square into four triangles (draw an X through each square). This gives you 48 large keys on the screen. I tried "typing" on my keyboard with my stylus (as it's the size of a DS screen) and found it quite comfortable, obviously a bit slow because I hadn't optimized it (just alphabetical order) but it took almost no effort to ensure I pressed the correct key.
A full keyboard has A-Z, a-z, 0-9, and ~`!@#$%^&*()-_+={}[]|\:;"'<>,.?/ space enter backspace tab. This is a total of 98 characters. If you use 2 pages of 48 keys each, that's 96 characters - each page can hold the entire upper or lowercase alphabet plus 22 other keys, and then you have two more characters you need to fit in somewhere.
My solution to the two extras was to use the Dpad: Up switches pages (consider it Shift), Left is backspace, Right is space, and Down is Enter - just like in TxtWriter. Then on the screen:
Page 1: a-z 0-9 .,?!+-*/"'\=
Page 2: A-Z @^<>~&%$#_()'"| tab ? caps []{}
By moving these control keys to the D-pad I had space left over for caps lock and an extra character, I chose the degree symbol here.
These layouts aren't in any order right now, but I did try to put the symbols that I felt would be most common on page 1. Does anyone else like this idea?
_________________
I'm a PSP hacker now, but I still <3 DS.
#118664 - JessTicular - Thu Feb 15, 2007 9:53 am
Ok, so if the T9 algo is patented, why can't we come up with our own that does the same thing?
C'mon, we're intelligent software developers, right?
In essense, it's a dictionary lookup, yeah?
You punch a key, it has one of three possible letters, so you extract all words from the dictionary that have that starting letter.
Then, you punch another key - do the same again, but the restriction on words is greater now. So on, till the user either hits space (confirming the word), or presses a key to cycle the available words.
As a basic implimentation, you would order the words alphabetically, but if you trained the dictionary, then you could have the most common words first (an easy way to do this is to feed it digital books, make it log how many times each word appears, and rearrange based on the most common).
So, I bet that's not the T9 algorithm, but to the user it's pretty much identical.
The only major problem I can see is that extracting words would take O(n), so a faster (non-linear) method would have to be devised. (Maybe Binary tree's or some-such?).
So... whaddya think?
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org
#118666 - OOPMan - Thu Feb 15, 2007 9:57 am
Hmmmm, sounds okay Hyper :-) Are we going to see a demo soon then?
Jess, with regards to the dictionary look-up it sounds interesting. Of course, it needs to be handled efficiently and have a good interface. I for one find T9 to be a mixed blessing. Useful in some ways, horribly stupid and irritating in others.
On my end, I'm probably going to start working on the QuickKeys idea today, although with some mods. (Mainly in that I'm shifting the char count per page to 40 [Down from 64] because it allows some useful tricks and with 3 page sums up a keyboard nicely :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#118673 - JessTicular - Thu Feb 15, 2007 12:14 pm
To be completely honest, I don't think efficiency would be that much of an issue.
Even if we used a linear O(n) dictionary lookup, it would still be faster than what the user can type.
I would imagine, even the most proficient at Predictive Text could only do roughly 3 words a second, which is pretty slow if you think about how fast some people can type on a keyboard :P
[EDIT]
But, of course, the more efficient, the better!
[/EDIT]
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org
#118678 - tepples - Thu Feb 15, 2007 1:47 pm
| JessTicular wrote: |
| I would imagine, even the most proficient at Predictive Text could only do roughly 3 words a second, which is pretty slow if you think about how fast some people can type on a keyboard :P |
Human conversation runs about 3 words per second. Even I can only type about 1.5.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#118736 - HyperHacker - Fri Feb 16, 2007 8:18 am
| OOPMan wrote: |
| Hmmmm, sounds okay Hyper :-) Are we going to see a demo soon then? |
Not soon (too damn busy) but I was planning to toss a few of the ideas from this thread into a demo app so people could experiment with them and see how well they actually work.
_________________
I'm a PSP hacker now, but I still <3 DS.
#118798 - Darkflame - Fri Feb 16, 2007 9:48 pm
| tepples wrote: |
| Darkflame wrote: | | tepples wrote: | | So you'd have to hunt and peck every other letter. That could get complicated. |
I dont think we have letter memory at all on the current keyboard anyway. |
No, but I know Q is always on the left side of QWERTY and P is always on the right side. Muscle memory gets me to within a key of my destination, and then I correct just before a tap. |
Easy answere:
The most common next-letters are arranged at the center out, as I preposed.
However, within each "priority grouping" they are in alphabetical. (with some letters missing).
That would get you "in the region" in that split second.
It would be thus no worse then the normal keyboard in that regard.
Yet you have the avantage of moving the stylus a lot less, and often typeing two letters at once.
Im pretty sure, however, you would be able to type very fast on my preposed system after very little practice.
It all hinges on how good it would be at predicting the middle group of "potential" letters.
Im pretty sure under 99% of the time the next letter would be within that group.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#118826 - JessTicular - Sat Feb 17, 2007 4:13 am
Darkflame,
Like I proposed for my Predictive Text implimentation, you can train the dictionary by feeding it a couple hundred digital books. That'll mean you can order the words (or letter combo's) so that you know what usually comes after what :)
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org
#118885 - Darkflame - Sat Feb 17, 2007 8:26 pm
Yes, your right.
That probably is the easiest way to get the raw data.
Potentialy, purhapes a ultility could be made to make a "letter group order" file from a source.
That way multi-langerages could be supported asily.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
![[Images not permitted - Click here to view it]](http://lickr.org/files/nds/pointprediction.gif){kind=link}
![[Images not permitted - Click here to view it]](http://arlow.dyndns.org/view.png){kind=link}
![[Images not permitted - Click here to view it]](http://arlow.dyndns.org/view2.png){kind=link}