• You are not logged in.
  • Index
  • General
  • Proof of concept: OSD Keyboard On Demand

    Proof of concept: OSD Keyboard On Demand

    • Started by ezuk
    • 3 Replies:
    • Reputation: 0
    • Registered: 12-Jul-2008
    • Posts: 76

    I've made an attempt at designing a new kind of on-screen keyboard, for people learning to touch type.

    These were my base assumptions:

    1) An on-screen keyboard is not easy to look at. It is a complex visual element. Finding the key you're looking for takes time.

    2) Most of the time, you don't need the whole keyboard.

    3) The most common use of an on-screen keyboard, when learning to touch type using a new layout, is correcting typos.

    4) (And this one is not really correct: ) Most typos are 'finger slips', which happen when the user hits an adjacent key by mistake.

    5) When learning a new layout, you get to a point where you have a rough idea of where the key you're looking for is located, but you're not quite sure.

    I stand firm behind 1-3. 4 is probably wrong, which is why this keyboard is only a proof-of-concept (along with some other reasons, see below).

    Basically what it does: Finds out what was the last character you deleted (presumably to correct a typo), and shows you what characters are adjacent to it on the keyboard.

    osdkeyboardyw2.th.png

    Click here for larger image.

    Current major problems in the script:

    1) The method used for getting the last key deleted is really stupid. I copy it to the clipboard, and it's really unreliable. Fortunately, the script is modular and this function can (and should be) easily replaced without changing anything else. I tried an in-memory keylogger routine as an alternative, but it had its own issues.

    2) With frequent use, the script can be irritating. There should be a delay before showing the OSD, but I'm not sure how to implement it ("Sleep" or "A_TimeIdlePhysical" does not really cut it).

    3) There's more, but honestly, I am sure others would be quick to point them out and I'm really tired (stayed up late coding this).

    Bottom line: Tell me if you like the idea, and if you feel like making it better (both in idea and in implementation)

    #SingleInstance Force
    Gui, +LastFound +AlwaysOnTop -Caption +Owner
    Gui, color, 000000
    WinSet, Transparent, 150
    Gui, font,w500 s50 ccccccc, Calibri 
    Gui, Add, Text, center vFarLeft y0, 
    Gui, Add, Text, center vLeft y0, 
    Gui, font, cYellow 
    Gui, Add, Text, center vMiddle y0, 
    Gui, font, ccccccc
    Gui, Add, Text, center vRight y0, 
    Gui, Add, Text, center vFarRight y0, 
    WinY := A_ScreenHeight-130
    
    Loop, 0x6B
      Hotkey, % "*~" . chr(A_Index+20), HideUI
    
    return
    
    Backspace::
    CapsLock::
    KeyToAnalyize:=ObtainKey()
    LettersToShow:=AnalyzeKeys(KeyToAnalyize)
    UpdateUI(LettersToShow)
    Gosub,ShowUI
    return
    
    
    ObtainKey()
    {
    clipbackup:=ClipboardAll
    Send, +{Left}^x
    KeyDeleted:=Clipboard
    Clipboard:=Clipbackup
    Clipbackup:=
    return %KeyDeleted%
    }
    
    AnalyzeKeys(KeyPressed)
    {
    global
    q = ##QWE
    w = #QWER
    e = QWERT
    r = WERTY
    t = ERTYL
    y = RTYLU
    l = TYLUO
    u = YLUOP
    o = LUOP#
    p = UOP##
    a = ##ASD
    s = #ASDF
    d = ASDFG
    f = SDFGH
    g = DFGHJ
    h = FGHJK
    j = ghjki
    k = hjki#
    i = JKI##
    z = ##ZXC
    x = #ZXCV
    c = ZXCVB
    v = XCVBN
    b = CVBNM
    n = VBNM#
    m = BNM##
    Loop 26
      {
        Test:=chr(a_index+96)
        If (KeyPressed = chr(A_Index+96))
          {
          LetterPressed := chr(A_Index+96)
          Display := %LetterPressed%
          NewLetter := Yes
          Return Display
          } Else {
          Newletter := No
          }
      }
    }
    
    UpdateUI(keys)
    {
    global
    stringsplit,stroke,keys
    FarLeft =
    Left = 
    Right =
    FarRight = 
    If (stroke1 <> "#") {
      FarLeft:=stroke1
    }
    
    If (stroke2 <> "#") {
      Left:=stroke2
    }
    
      Middle:=stroke3
    
    If (stroke4 <> "#") {
      Right:=stroke4
    }
    
    If (stroke5 <> "#") {
      FarRight:=stroke5
    }
    
    GuiControl,Text,FarLeft,%FarLeft%
    GuiControl,Text,Left,%Left%
    GuiControl,Text,Middle,%Middle%
    GuiControl,Text,Right,%Right%
    GuiControl,Text,FarRight,%FarRight%
    
    }
    
    ShowUI:
      If (NewLetter = Yes) {
      Gui, Show,hide xCenter y%WinY% h93 NA,
      }
      NewLetter := No 
    return
    
    HideUI:
    Gui, hide
    return
    Offline
    • 0
    • Reputation: 0
    • Registered: 08-Mar-2008
    • Posts: 303

    That's pretty clever, and could be useful in learning a new layout. But if you already know the general area of the key you hit, couldn't you just find that area on a whole keyboard just as easily? Also, it would be completely ineffective for non-adjacent errors. What if you are trying to hit E on Colemak, but instead hit its QWERTY position? That's on the total other side of the keyboard, and seems like a potentially common error. And it would be common not just when learning the layout, but while trying to maintain speed on both layouts. Due to the way Colemak was made, that type of error will be less common because most moved keys are close to their original position, but there are still some. E happens to be the most common key, making up 13% of all letters typed. So it would be in about 13% of all errors. It would actually be involved in 25% of all errors, and be the typed key/the meant to be typed key 13% of the time. You understand what I mean if you know probability, and if you don't, I don't feel like explaining it. But anyway, the point is, your method is a good idea assuming that errors are adjacent. That is frequently true, but I don't think often enough for this to be worth it. It would have to be nearly all the time, considering how hard it would become to find non-adjacent keys.

    Offline
    • 0
    • Reputation: 0
    • Registered: 12-Jul-2008
    • Posts: 76

    Dude, way to go on the attitude. Wow.

    Anyway, to try give a polite reply:

    1) I said it's alpha, far from a perfect concept.

    2) The char-dependant messages could be customized easily. I could even show an image. So for something as common as the E error (which is a phase in learning, too) we could show a custom text or visual 'tooltip'.

    If you were actually into the idea akd felt like helping to improve it, I would elaborate. But I get a feeling that's not really the case...

    Offline
    • 0
    • Reputation: 0
    • Registered: 08-Mar-2008
    • Posts: 303
    ezuk said:

    Dude, way to go on the attitude. Wow.

    Anyway, to try give a polite reply:

    1) I said it's alpha, far from a perfect concept.

    ...

    If you were actually into the idea akd felt like helping to improve it, I would elaborate. But I get a feeling that's not really the case...

    Apparently you thought I was being rude and/or overly critical. That wasn't my intention. What I meant was, that concept has limited practicality and could be improved. I was explaining the flaws, because the first step to fixing them is knowing what they are. I was in a hurry (plus I'm lazy) so I didn't come up with a way to fix the flaws. But I will now.

    Are you trying to make something with that concept, or just make something that helps reduce errors? If you're trying to reduce errors, you could have the program try to guess what key was meant to be typed. You could have a little dictionary, and it will show all the possible keys that would make that a real word.

    2) The char-dependant messages could be customized easily. I could even show an image. So for something as common as the E error (which is a phase in learning, too) we could show a custom text or visual 'tooltip'.

    What do you have in mind here? What sort of customization?

    Offline
    • 0
      • Index
      • General
      • Proof of concept: OSD Keyboard On Demand