I would like a personalized buttonboard layout for use with the computers at the public library.
Considering an HTM doc with JavaScript remapping the buttons pressed to the desired characters. Then I could just copy paste whatever I typed, from there to wherever.
Dell wired keyboard, model KB216t1. Drawn without the extended section, f.e. numeric buttonpad. The right-side buttons are larger than the left-side buttons, for whatever reason.
.---. .---------------. .--------------. .---------------. |esc| |F1 F2 F3 F4 | |F5 F6 F7 F8| |F9 F10 F11 F12| '---' '---------------' '--------------' '---------------' .---------------------------------------------------.-------. | ` 1 2 3 4 5 6 7 8 9 0 - = | b-del| >-----.---------------------------------------------^-.-----< |tab | q w e r t y u i o p [ ] | \ | >-----^.-------------------------------------------.--^-----< |caps | a s d f g h j k l ; ' | enter| >------^-.---------------------------------------.-^--------< |shift | z x c v b n m , . / | shift| >----.---^---.---.-----------------------.---.---^---.------< |ctrl|fn |win|alt| barbutton |alt| fn|ctx| ctrl| '----^---^---^---^-----------------------^---^---^---^------'
The
The following is a chart pairing the label printed on the button with its revealed name ("Identify buttons [#∞]"). No name revealed for the "Fn" buttons, so they seem to be undetectable from the HTM docviewer.
Esc F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ Escape F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 ` 1 2 3 4 5 6 7 8 9 0 - = Backspace --------- ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ---------------- Backquote Digit1 Digit2 Digit3 Digit4 Digit5 Digit6 Digit7 Digit8 Digit9 Digit0 Minus Equal Backspace Tab Q W E R T Y U I O P [ ] \ ------------- ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ----------- ------------ --------- Tab KeyQ KeyW KeyE KeyR KeyT KeyY KeyU KeyI KeyO KeyP BracketLeft BracketRight Backslash CapsLock A S D F G H J K L ; ' Enter --------------- ------ ------ ------ ------ ------ ------ ------ ------ ------ --------- ------ ----------------------- CapsLock KeyA KeyS KeyD KeyF KeyG KeyH KeyJ KeyK KeyL Semicolon Quote Enter Shift Z X C V B N M , . / Shift ------------------- ------ ------ ------ ------ ------ ------ ------ ------ -------- ------- --------------------------- ShiftLeft KeyZ KeyX KeyC KeyV KeyB KeyN KeyM Comma Period Slash ShiftRight Ctrl Fn [win] Alt [barbutton] Alt Fn [ctx] Ctrl ----------- ------ -------- ------- ------------------------------------------- -------- ------- ------------- ------------ ControlLeft MetaLeft AltLeft Space AltRight ContextMenu ControlRight
Seems like most all buttonboards are one-size-fits-all, disregarding the different sizes of hand and fingertips, and disregarding the lengths of each finger for their reach. The buttons for typing symbols are squarish, with a gap in between them that is about one-third the width of such buttons. That means each button is three units in width and length, and the width of other types of buttons tend to be a multiple of the same base unit, too. The F-number buttons are sometimes slightly wider or half as long, and might be spaced a little further apart.
That makes drawing the buttons consistent, usually three characters wide with the button symbol for the middle character, and usually spaces as the first and third characters, f.e. " A ". Buttons can share side and top boundaries, such as a vertical bar "|" for the sides and hypens "-" for the horizontal boundaries.
In the drawing of the Dell wired keyboard, model KB216t1 [#1], most of the vetical lines for the buttons are left out so the layout of the symbols can be observed without distraction. The larger buttons retain their boundaries, and a couple of additional symbols help emphasize their shape.
Too many different symbols for the edges of the buttons and their board has seemed to attract too much attention; the symbols and names are more important. See buttonboard.htm for various drawings of the "Apple Model A1243" buttonboard.
As I have done before, one button for each letter of the alphabet, half for the left and half for the right. Three buttons for each of four fingers handles twelve of the thirteen for each half. The forefinger of each hand will handle the additional button, with "y" for the left and "z" for the right.
a b c d e f g h
i j k l y z m n o p
q r s t u v w x
The various layouts would be similar to the "compact buttonboard layout" docs for the "Raspberry Pi model RPI-KYB" [xmodmap--compact--rpi-kyb.htm] and the "Apple model A1243" [xmodmap--compact--apple-a1243.htm].
The following chart shows the symbols for each button, essentially four layouts: "small letters" (lower left), "capital letters" (upper left), "numbers and punctuation" (lower right), and "diacriticals and more punctuation" (upper right).
A { B } C < D > E \ F / G * H =
a ( b ) c [ d ] e 1 f 2 g 3 h -
I ̈ J ̧ K ̄ L ¡ Y ¿ Z # M & N | O @ P :
i " j , k ʻ l ! y ? z 0 m 4 n 5 o 6 p .
Q ̀ R ̃ S ̂ T ́ U _ V $ W % X ;
q ` r ~ s ^ t ' u 7 v 8 w 9 x +
Four layouts using the same 26 buttons allows for 104 symbols instead of only 94 (52 alphabetic, 42 numbers and symbols). The additional symbols include the inverted exclamation mark (with "l") and the inverted question mark (with "y"). An additional letter is for the consonant ʻokina placed with "k", as the "k" is a nice mnemonic for both the consonant ʻokina and the kahakō combining diacritical mark.
The ʻokina is in the same layout as the common punctuation (comma, period, and so on) and numbers, because I consider those to be the next most common set of symbols. The combining diacritical marks is the alternate layout to that one, mostly for the opportunity for associating the diacritical marks with the same button that have the traditional symbols used for invoking them.
There are seven combining diacritical marks represented in that chart in the upper right of seven of the groups. The kahakō combining diacritical mark is shown next to capital letter K, above the ʻokina consonant (next to the small letter k). The other six are to the right of the capital letters: I, J, Q, R, S, T. These six are also above the similar characters which have been traditionally used for invoking them: double-quote, comma, back-quote (or backtick), tilde, caret, apostrophe (or single-quote).
The following is a list of the seven diacriticals proposed for this set of layouts.
trema: ̈ as with "bilingüe" [for either umlaut or diaeresis]
cedilla: ̧ as with "façade"
kahakō: ̄ as with "kahakō"
grave: ̀ as with "à la mode"
tilde: ̃ as with "eñe"
circumflex: ̂ as with "você"
acute: ́ as with "café"
The main idea for switching between layouts has been that of thinking of them as paired: layout of "small letters" paired with "layout of capital" letters; layout of "numbers and punctuation" paired with "diacriticals and more punctuation". Similar to using the "Shift" modifier buttons, a button would switch to a different layout: one for the "upper" layouts, and one for the "rightside" layouts. However, I am favoring "lock" buttons similar to a "Shift Lock" button, so as to have more freedom without anchoring a finger for holding a typical modifier button.
The default layout is "small letters". The "capital letters" layout is accessed with the "upper lock" button.
The "numbers and punctuation" layout is accessed with the "right lock" button. The "diacriticals and more punctuation" is accessed when both "right lock" and "upper lock" buttons are active.
Long ago, sometimes a buttonboard made the "Shift Lock" button (or "Caps Lock" button) remain physically depressed when locked, which made it possible to know by touch whether it was active. Sometime later having instead a light on the buttonboard (sometimes no where near the lock button itself) that had to be visually looked at became more common, thereby inhibiting touch-typing. This was sometimes compensated for by visually indicating within a computer program (f.e. a text editor) when a modifer button was locked, then there was no need to look at the buttonboard for confirmation.
As such, planning on having a similar visual indicator for the locked layout buttons ("right lock" and "upper lock") on the computer display for these layouts. Preferably very near where the typing is occuring, which is especially important with huge computer displays.
Another idea is to have a separate button for each layout. For example: AltLeft for "small letters"; x for "capital letters"; period (.) for "diacriticals and more punctuation"; and AltRight for "numbers and punctuation".
1 2 4 5 9 0 = BDel
--- --- --- --- --- --- --- ----
A { B } C < D > E \ F / G * H =
a ( b ) c [ d ] e 1 f 2 g 3 h -
q w e r t i o p [ ]
--- --- --- --- --- --- --- --- --- ---
I ̈ J ̧ K ̄ L ¡ Y ¿ Z # M & N | O @ P :
i " j , k ʻ l ! y ? z 0 m 4 n 5 o 6 p .
a s d f l ; ' Enter
--- --- --- --- --- --- --- -----
Q ̀ R ̃ S ̂ T ́ U _ V $ W % X ;
q ` r ~ s ^ t ' u 7 v 8 w 9 x +
For the four fingers of each hand. Left forefinger begins over the "r" button, and right forefinger begins over the "o" button.
The outer two fingers seem more comfortable reaching outward more. For the left hand, that means buttons "1" and "2" rather than "2" and "3". For the right hand, that means buttons "=" and "BDel" rather than "-" and "=".
Refer to section "2. Symbol Layouts" [#2] for an explanation of the additional combining diacritical marks and other symbols.
z x c v
~~~~~ ~~~~~ ~~~~~ ~~~~~
Newline B-Del Space F-Del
v
left thumb--> <--
^
Alt barbutton
~~~~~ ~~~~~~~~~~~~~~~
"lock "show layout"
upper"
For the left thumb.
k
~~~~~
Up
Prior
m , .
~~~~~ ~~~~~ ~~~~~
Down Left Right
Next Begin End
v
--> <--right thumb
^
barbutton Alt
~~~~~~~~~~~~~~~ ~~~~~
"show layout" "lock
right"
For the right thumb.
Remap the The Control and Alt buttons can stay the same, because this is just an override with a computer program (t.i. the HTM docviewer) rather than an override of the OS. The "Windows" button (MetaLeft) stays the same, as well as the
In general, no need for a Tab button because I deplore indentation. While Tab is useful for shifting the focus amongst various text fields, checkboxes, and so forth within a computer program, that would be outside the editing area. Whenever needed, a command can be addded for shifting focus away from the editing area, thereby re-enabling the default buttonboard layout, hence the Tab button, too.
General function use and naming conventions in the scripts (a.k.a. computer instructions). Inspired by the doc: "Cursor halving" [cursor-halving.lisp.html#general].
"remap_": Collective prefix for symbols.
No capital letters, f.e. camelCasingNames, because that is what is done in the document object model (DOM) [dom.spec.whatwg.org] referenced by and used in the HTML standard [html.spec.whatwg.org]. The similarity can lead to confusion of where to seek documentation.
ID names for HTM marks are hyphenated; no capital letters. (Will add/change conditions for IDs later...)
There are a plethora of approaches for associating a set of replacement symbols with each button by means of JavaScript, such as double-quoted text or a two-dimensional array holding the lists. A few examples:
A two dimensional array structured like a table of rows and columns:
[ ["Digit1" "Digit2" "Digit3" ...], ["a" "b" "c" ...], ["A" "B" "C" ...], ... ]
Or pair the button name with its list of symbols:
[
["Digit1" "a A ( {"],
["Digit2" "b B ) }"],
["Digit3" "c C [ <"],
...
]
There are also many different ways of marking the lists with HTM. The HTM marks substitute for the quotation marks and commas.
ol or ul.
Maybe use a description list dl by marking the button name with dt and then mark each symbol for it with a dd. Some CSS style can compact it.
Similiar to one of the aforementioned examples of JavaScript arrays, the lists could be rows of a table, and then referenced in resulting DOM by means of querySelector() with JavaScript. There could be multiple tables, such as a table for each row of 8 or 10 buttons.
| layouts | Digit1 | Digit2 | Digit3 | ... |
|---|---|---|---|---|
| small letter | a | b | c | ... |
| capital letter | A | B | C | ... |
| ... |
<pre>, like what has already been done for some of the earlier diagrams, and format it with just spaces. Access it with JavaScript, then split the text by line, and then split each line by spaces (probably compacted first).
[...just for fun, trying out DL within TD...as a square of symbols...]
[...hmm, this is actually rather efficient in plain text; one button per line, easy to maintain...]
| rows | Left hand | Right hand | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| row 1 |
|
|
|
|
|
|
|
| ||
| row 2 |
|
|
|
|
|
|
|
|
|
|
Marking the lists with HTM would make the lists as both documentation for reference and as data for computer instructions. That avoids discrepencies that might occur trying to maintain two separate listings, and makes the data accessible without needing to deeply peruse computer instructions. Of course, the data could be copied from the DOM into whatever JavaScript format desired, thereby accessing the DOM for the data only once rather than with every button typed.
A copy of the script for identifying the buttons could help with repetitious typing (Identify buttons [#∞]). Consider having it automatically add quotes, or commas, or HTM marks, or whatever, when typing each button. Then type one row of buttons, copy the output, and paste wherever in this document.
Insert a symbol from the "small letters" layout.
Input: type a symbol and it will be matched with the symbol from the "small letters" layout. The symbol from the layout will be appear instead of the typed symbol. [Favoring "1345" rather than "1245", and "90-" rather than "90=".]
These are the supported buttons for this script.
The script.
Identify a typed button.
The input and output.
[type here]
The script.
Some results.
[ Would like to rephrase the statements below; they were just quick notes while testing... The term "bypassed" is actually refrerring to the operating system keeping the event for itself without passing it along to the HTM docviewer. The term "captured" is referring to the event being given to the HTM docviewer and thence available to the script; unless it says the system (t.i. operating system, a.k.a. OS) "captures" the event or button. ]
Seems to be no need for the event.stopPropogation() as of yet, but less bubbling might be more efficient.
Seems like:
Seems like ShiftLeft and ShiftRight buttons are captured.
Seems like the AltLeft and AltRight buttons are captured, as there is no focus of the "..." menu in HTM docviewer.)
Except Alt + Tab for switching views is captured by system (Alt is captured, Tab missed).
But I have no interest in the Tab character anyway.
Seems like the CtrlLeft and CtrlRight buttons are captured.
Except the SAM context menu appears with Ctrl + Tab (Ctrl is captured, Tab missed). No event received by the HTM docviewer when dismissing that menu with Esc. Admin required to enable/disable SAM.
But I have no interest in the Tab character anyway.
Bypassed by the "Windows" button (MetaLeft), t.i. the system menu still appears.
But the event in the docviewer is available when activating, hence able to confirm it is MetaLeft.
However, the event for dismissing the system menu (either Meta button or Esc button) is captured by the system, hence the docviewer never gets it.
The OS responds to the
Bypassed by the NumLock and CapsLock, t.i. the number lock and caps lock are still toggled. But the event in the docviewer is available, hence able to get the code for each button.
Bypassed by the Fn button, no event for the docviewer, or at least no code for the button. Also when Fn is used with F9 (missed) to activate "Search", or with Esc (missed) to lock Fn.
Buttonboard layouts for an Xserver (the X11 protocol).
Conditions and typical keyboards; proposed layouts; alternate keyboards.
Excerpt:
Complete requests or follow a set of instructions.
Perform a sequence of actions at the push of a button.
Observe a demonstration of actions and repeat those actions when requested.
Work on a copy.
Various official recommendations and standards.