Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Den

Pages: [1] 2 3 4 ... 22
Programming / Re: Versatile Separated Values (VSV)
« on: November 15, 2017, 07:58:13 AM »
VSV Usage examples and comparison to other formats

VSV as Tabular Data

Double Matching Brackets are header fields (optional)
Everything else are data rows

(When using the Comma , as delimiter, similar to CSV)

Code: [Select]
((Name)) ((Score 1)) ((Score 2))
,BEAKL 8, 104, 132
,BEAKL 9, 120, 144
,BEAKL 10, 44, 99

NameScore 1Score 2
BEAKL 8 104 132
BEAKL 9 120 144
BEAKL 10 44 99

(Can use any nonspace character as delimiter--lots of freedom)

Code: [Select]
[[Name]] {{Age}} ((Gender))
,Hammie, 20.5, F
-Chow, Vivian-40-F
*Shena'Fu *18+5/12 *F
|Grndr-1245|21 months||
Fairy Nuff 14 K N/A

Hammie 20.5 F
Chow, Vivian40F
Shena'Fu 18+5/12 F
Grndr-124521 months
Fairy Nuff14 KN/A

VSV as Linux password file

The Colon :  starts each line and separates each field

Code: [Select]
:smithj:x:561:561:Joe Smith:/home/smithj:/bin/bash

VSV as configuration file

Double Square Brackets [[ starts each section
Double Round Brackets (( are comments and help
The Equal = starts each line and separates the setting key from its value

Code: [Select]
((display options: fullscreen, windowed, windowedmax))

VSV as XML replacement

Double Angled Brackets << as tags
Close innermost tag with the Slash / inside double brackets
Data rows as attributes and content
Use spaces to indent

Code: [Select]
   ~txt~Don't forget me this weekend!

VSV as Objects and Arrays

Double Curly Brackets {{ as Objects
Double Square Brackets [[ as Arrays
Close innermost object or array with the Semicolon ; inside double brackets
Data rows as properties
Use spaces to indent

Code: [Select]

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 13, 2017, 06:06:47 PM »

What keyboard(s) do you use to type BEAKL 9 on?



Kinesis Advantage2 (cheaper elsewhere)

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 12, 2017, 12:08:01 PM »
Impressive. I'm probably around 30 wpm still. I think it's week 6 on BEAKL 9. Of course, I've only recently switched full-time. Ended up having to switch entirely as my typing on a dvorak kinesis advantage at work has seriously degraded. Due to the 'key confusion,' I'm about 30-ish on both layouts at the moment. Guess, I was unable to maintain both. Incidentally, that is what I wanted to know.

It helped that I had been using BEAKL EZ prior for a while. The 9 most common letters are in the same places between BEAKL EZ and BEAKL 9. So the transition is easier this time around.

After using Dvorak for years, it began to fit like a glove, second nature. So it'll take yet longer than a month or two to regain the same feeling of mastery with a new layout.

Programming / Versatile Separated Values (VSV)
« on: November 12, 2017, 06:05:20 AM »
Versatile Separated Values (VSV)

Proposal: A versatile, efficient, unambiguous, standardized, simple text format for creating tables and lists that's easily read and created by both humans and machines, that supports many variations for any personal style, preferences, and protocols. Can accept any nonspace character (including comma, colon, tab, asterisk, etc.) as delimiter automatically without user input (no annoying popups or options to fill in).

The same simple algorithm will accept almost any delimiter you want. You want commas like CSV? No problem. Or fields separated by tab (TSV)? Sure. How about *NIX files that use colons? We'll take it. Want to mix them up in the same table or file? Go ahead.

Exporting to VSV (creating files)

Rows are separated by newline. 

Header rows are optional. Each header field is enclosed by any of these double matching bracket types:
Code: [Select]

Different header fields may use different brackets types. Mixed bracket types may be employed on the same header row.

When exporting to a VSV file, characters that are found in a header field must not be used as enclosing brackets for that field. Choose a bracket not found in that field to surround that field.

Data rows (non headers) must be led by an explicit nonspace character, called delimiter. Values for that row are placed between two delimiters. The first occurrence of a delimiter on that row is not counted as part of the values.

A null value has zero length, signified by consecutive delimiters with nothing in between them.

A delimiter at the end of the line after the final value is optional, unless the final value is a null value.

Each row may have its own distinct delimiter. A text file may have different rows with various delimiters. Creators can use the same delimiters or mix them for different rows, as long as the desired values on that row are distinguishable (i.e. to prevent delimiter collision.)

When exporting to a VSV file, characters that are found in the values of a given row must not be used as delimiter for that row. Choose a character not found in that row's values as the delimiter for that row.
  • Space and newline cannot be used as delimiter. Any other single character may be used.
  • Letters and numbers may be used as delimiters, but are not recommended.
  • Avoid using header field brackets as data row delimiters. Nevertheless, single bracket at beginning of a row should be read as a legal delimiter.
  • Creators may have their own preferred delimiters. Common delimiters to use:
Code: [Select]

Importing VSV (reading files)

Rows are separated by newline. Leading spaces on each row are discarded and ignored.

If the first two nonspace characters of a row are identical opening brackets, this is a header row. Else it is a data row.

Header fields must be enclosed by both an opening and a closing matching double brackets. Any other text on a header row is discarded and ignored.

The first nonspace character of a data row is its delimiter. The values of this row are stored between two delimiters or the end of line. A value can have zero length, or null value. There is no value between a line-ending delimiter and end of line (it doesn't count as another value, not even null value).

In PHP, use the explode() function to store a row's values into an array split by the delimiter. For other languages, use a regexp to match the values separated by the delimiter.


See :


How to handle values that contain newline?
Can it be used for objects or hierarchy? i.e. in place of JSON, XML, HTML
Can it be used as configuration file? cf. INI, CONF files

Keyboards and Other Interfaces / Re: WordCount metrics
« on: November 11, 2017, 03:55:51 PM »
for comparison, the bottom end looks like this, with the worrying inclusion of Amuseum (and Plum Ergolinear, for that matter):

Don't be too concerned for Amuseum layout. It was designed for rolls. So in fact it doesn't mind the long one-hand sequences.

Keyboards and Other Interfaces / Re: WordCount metrics
« on: November 11, 2017, 01:55:26 AM »
Finally dawned on me the problem with the one-hand metrics, as regards AltGr layouts ... I was ignoring which hand the needed thumb was on.
So I need to see where the Shifts and AltGrs are, how they are used, and then only use letters accessed by them if on same hand.

Biggest effect is going to be on the SC layouts.

Dunno if Den is using same methodology, or doing what I was doing previously and just looking which hand is used to press the key ...

For SingleHand words, Shifts and AltGrs are transparent. That is, they don't add or subtract to the handed-ness. They are just helpers to access letters on different layers--even if they are opposite hand. Ultimately the letters are still typed on the same hand, including stuff like rolls, row jumps, same fingers, etc. are still happening with the non-thumb fingers. Therefore effort is expended likewise as if on the same layers.

Seelpy 1.5 still has good Words score on KLAtest despite that. The excellent HomeBlock score compensates for bad SingleHand score, but overall is quite competitive in this category.

re: overall Words scores

Some layouts really stumble on this category. Including Arensito, Colemak, BEPO, etc. As expected from low hand-alternation layouts, which leads to lengthy one-handed strings, up to 10, 12, 14 letters consecutively on the same hand (according to your chart)--that's ridiculously inefficient.

Keyboards and Other Interfaces / Re: Guilty as charged
« on: November 10, 2017, 09:30:00 PM »
Will the accused please rise?


Skip to the "Keyboard Design: Universal, Ideal, and Simplified" part.

Ya of course there's parties interested to maintain QWERTY as the standard.

It's also amazing that people were able to hit 140 WPM with those ancient typewriters with steep rows.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 10, 2017, 09:10:33 PM »
BEAKL 9 (Personal speed typing progress)

Corpus Sight Words (Easy-to-type)
Type Random Words
Test Results
Speed 76 WPM
Accuracy 96.3 %
Correct Entries 367
Incorrect Entries 14
Fixed Mistakes 14
Total Entries 381
Error Rate 0
Raw Speed 76 WPM
Key Speed 381 KPM
Complete Words 82
Total Time 1 min(s)

Corpus The Fox and the Goat
Author Aesop
Type Fables (Easy to type)
Test Results
Speed 74 WPM
Accuracy 95.7 %
Correct Entries 356
Incorrect Entries 16
Fixed Mistakes 16
Total Entries 372
Error Rate 0
Raw Speed 74 WPM
Key Speed 372 KPM
Complete Words 75
Total Time 1 min(s)

Only been with BEAKL 9 for around 40 days, and already up to 75 WPM (started at around 55-60). I think it's pretty good progress, and shows that this layout is easy and has low learning curve. I don't practice and hone speed typing, but naturally improving by using it for everything. Still make too many errors, though.

I seem to type faster when leaning back, arms stretched out. Elbows at right angles can feel too stiff and not as mobile.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 08, 2017, 10:46:45 AM »
Colemak forums used to be popular to discuss alternative layouts. But it stagnated since AdNW. which the Germans / Europeans now much more receptive to discovering better layouts. Even France considering changing national layout to Bepo, a Dvorak like layout. Too bad I don't understand their languages to join in their discussions.

Keyboards and Other Interfaces / Re: WordCount metrics
« on: November 08, 2017, 04:25:36 AM »
If we average the HomeBlock and OneHand scores (ie one positive scoring, one negative scoring), we get the Top Ten:

Modified BEAKL54.75
Essie 3 Ergolinear wip52.6
Marsan English51.51
BEAKL 5 Matrix44.68
BEAKL CLP 042.23
BEAKL Opted36 (+Ergo)41.67
Einbinder Orthogonal   41.67
US Pat 3,929,216 mod Ian40.44
X7.1H Ergolinear40.13

Which is curious because apart from BEAKL variants and from me, the other three are from old layouts, some patented decades ago.

Maybe their "typewriter" design mindset co-incidentally resulted in layouts similar to what Den is now aiming at, with little pinky use.

Well, Einbinder does looks similar to 3-thumb-letter layouts like U_RN.

Marsan is really outlier. It doesn't have great home-block score, but it does have really great one-hand score; guess that evens out.

re: HomeKeys and HomeBlock

If we count every letter typed by keys in those regions, we get the percentage of letters typed by those keys. Perhaps a more practical metric--easier to measure and compare. For example, typing short words like 'a', 'or' on some layouts requires pinkies. Unfortunately this is not penalized if we only account for lengthier words.

OneHand stays to measure strings of three or more letter consecutively typed on the same hand. That is to say that we accept it as normal, acceptable to type single or pairs of letters on the same hand.

Keyboards and Other Interfaces / Re: Finger tip pain
« on: November 07, 2017, 08:12:59 PM »
Copy and paste are extremely common, repetitive functions across every application. For best effect:

- They should be activated by a single finger press; not combination.
- They should be placed in very convenient locations.

Single finger press means your whole hand is free to access the key, not bound to painful positions in awkward  combinations.

I put them on the mouse button activated by the thumb. My right hand is almost always on the mouse anyway. Using the mouse to select text, followed by mouse thumb keys to copy and paste, allows nice sequence.

If I intend to paste a lot in a short time and want to do it fast, occasionally I use the left hand to press the Escape key that has been replaced by paste function. Again no combination.

(It's not really Escape any more, whose function I have moved to the left shift location. The far corner key where Escape originally sat is reprogrammed to useless key--NumpadEnd--and became a macro in AutoHotkey to activate Ctrl-V. thus one-hit the old Escape key would paste stuff.)

Combinations, especially awkwardly caused by keys far apart and hit by the same hand, obviously not good to stretch your hand like that. More reason that more keys on a board are not necessarily better. They become convenience traps: look very convenient, but not necessarily ergonomic. Another reason to the distance theory has merit even outside of touch typing.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 05, 2017, 01:15:22 AM »
KLAtest scoring is teetered around a baseline average. It may seem scores are unfair, but that's only because those layouts are far worse than the average baseline.

I find myself doing things which I know don't make sense, like swapping z with " because that puts z on "home block" which boosts the "words on home block" score, which improves the overall score.

z is so rare (in English) that it shouldn't improve home block so much more than it negatively affects the other scores, like distance and finger usage.

the secondary issue is your selection on an imperfect corpus which has more z than ". so obviously that will mislead you to wrong solutions.

including pinky in the home block won't solve your particular case, nor affect anything in general. that's only moving the goalpost, moving the baseline, but the scores would stay relatively unchanged.

Consider the case between Arensito and Colemak. Both have AO on the pinkies. But Arensito maintains a high (good) score on Home Block Words category, however Colemak does poorly here. Suppose we include the pinky into home block. We can surmise that Colemak will perform better, but so will Arensito. Relatively speaking, Colemak will still score worse than Arensito.

NO pinky home block

Arensito 28.81
Colemak 35.74

WITH pinky

Arensito 4.48
Colemak 23.16

Relatively speaking, Colemak will actually lose points compared to Arensito. Arensito improved by 24 points, Colemak only 12. But that's not the whole story, since we have to readjust the baseline so that Words category is weighted fairly against the other categories. This means moving the baseline in the opposite direction of the shift in average scores. If the average score decreases, the baseline shifts up. In this case, probably end up with Arensito around 7.x and Colemak around 37.x.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 02, 2017, 02:05:49 AM »
Question: on Words tab, you have "Words" and "Total" columns... what's in the totals column?

Total accumulates the length of the words, or total letters counted. thus longer words will more quickly accumulate higher totals.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 01, 2017, 11:45:34 AM »
counting Whole words can be misleading. You can Type 10 keys on the same Hand, then 11th key on the opposite hand, but it doesn't count.

We should be counting any sequences of 4 or more consecutive key presses on the same hand. Ideally also take into account punctuations and numbers, if feasible.

Keyboards and Other Interfaces / Re: Schools of thought
« on: November 01, 2017, 02:59:32 AM »
School 1, aka Classical Touch Typing: if you're not using all 8 fingers, you are being inefficient.

That is the opposite of efficient. quoth the pros who study efficiency:

The economic efficiency of the worker often is no stronger than its weakest link.

What you have learned is that the capacity of the plant is equal to the capacity of its bottlenecks

"utilizing" a resource means making use of the resource in a way that moves the system toward the goal. "Activating" a resource is like pressing the ON switch of a machine; it runs whether or not there is any benefit to be derived from the work it’s doing.

You can only use one finger at a time. Thus you should try to use your strongest fingers as much as possible. When you stop using the pinky, the weakest link then points to another finger, probably the ring finger--which is a huge upgrade from the pinky.

cf. sports team playing their best players for maximum time and minimum rest. there are starters and there are bench players. its obvious why starters start and get the vast majority of the play time--because that gives them the best chance of winning--i.e. best efficiency.

School 2, aka BEAKL: avoid pinkies as much as possible, give the thumbs more to do.

thumbs are independent (e.g. not slowed by connecting fingers like pinky and ring), sturdy, fast. and on standard keyboard designs, vastly under-utilized.

There is also, I supposed, School 3, aka Use All You've Got... all ten fingers.... in suitable proportion. The pinky advantage is that it can move laterally better than ring and middle.

Why is that an advantage? The pinky is already slow at home key, why even bother stretching it and slowing down your typing even more? And risk damaging the fragile little thing from unsafe procedures?

I read recently that the allocation of A on QWERTY (and Colemak, and presumably O on Colemak too) annoys touch typists because it gives the pinky too much to do.

On the other hand.... when your kidnappers want to chop off a finger, don't let them take the pinky, it's very important for grabbing things.

Again, gripping and striking are very different things. and pinky is used more for balance than strength.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 01, 2017, 02:34:05 AM »
-- new tab: words
-- moved homeKeyWords, homeBlockWords chart to 'words' tab
-- new chart: singleHandWords
-- new score category: words via singleHandWords & homeBlockWords
-- synopsis of text

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 31, 2017, 01:39:07 PM »
-- added corpus: ASCII character test

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 31, 2017, 04:46:28 AM »
Words should be at least 2 letters long to be meaningful.

We know from Individual tests that Colemak does poorly in home block and one hand words test. So of course the aggregate of both values is just as poor.

The equation should be reversed to scale properly to other effort scores: one hand / home block.

Regardless there is a huge chasm between the best and worst layouts.

Another consideration is if left hand should be penalized a bit more, say 10% more than right hand, for all relevant scores (distance, fingers, same hand, words )

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 31, 2017, 01:14:56 AM »
The BEAKL layouts came out pretty well ... which I suppose vindicated the design objectives of "balance".

Low rates of words typed by the same hand tend to be the natural consequence of separating the vowels from consonants, and high hand alternation. AdNW/Opt tend to favor this style by default (influenced by Dvorak).

And then I realised that I have a new interesting word list to test with....

The little voice inside my head is mumbling about a possible new way to evaluate layouts.... ie
1. HomeKey words, higher is better
2. HomeBlock words, higher is better
3. Words on One Hand, lower is better.

Some sort of weighting of the three scores.
4. longest word on one hand, somewhere in the mix.

I don't know if this is a meaningful metric. On the one hand (whoops) typing is about typing words, so measuring "Ease of typing words" can be argued to be a relevant metric.
On the other hand, it ignores a lot of other things we think are important.

This could be a novel area of measurement that other analysis don't/rarely consider, and further differentiate the similar layouts. But the devil is in the details.

Effort scores scale upward toward higher score for more effort. Measurements must be formulated to scale in the same fashion.

#1 & #2 homekey words and home block words measure inversely to effort scale. So would need to formulated to scale appropriately.

#3 easier to work with. Two factors: word length and total amount. Issue to consider: should longer words cost more effort? (linearly? exponentially?)

#4 can be rolled into #3 if longer words are penalized more harshly.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 30, 2017, 11:00:01 PM »
Missing @ sign.

CRY Matrix is missing !

thanks :-)

Fixed both. Moved -_ to space. Should perform even better now.

Hacks / Better Tables in SMF forums
« on: October 27, 2017, 08:10:51 AM »
Need for simple ways to create tables in SMF forums.

1. Extend table code to allow various types of formats.

2. Common types of formats: csv, wiki, markdown, reStructuredText

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 27, 2017, 02:52:48 AM »
Here's a curve ball.... From a professor critiquing QWERTY.

Too little typing is carried out on the home row of keys (32%). Too much typing (52%) is
carried out on the top row. (Most critics of the QWERTY layout have assumed that
home-row keying is the fastest. However, that while this may have been so on manual
typewriters, top-row keying appears to be fastest for skilled typists on electric

If the professor is correct then the effort grids need to be rethunk...

What's his source? More importantly, what does he mean by that? Could it be that QWERTY typists are used to overusing the top row, therefore they type them faster. Or is it because they stretch (not curl) to type top row. But that doesn't explain why semi - common letters like N, M, C are two rows below the preferred top row.

Reiterate, do not conflate the terms: speed, effort, distance.

Effort grid is merely a visual aid to provide a direction. The actual parameters used will depend on the programs and algorithms. The actual effort cost and penalty will involve various factors like distance, finger (length), bigram, etc.

Unfortunately speed can't be determined or utilized by algorithms, as that is subjective and can be trained. on the contrary, You can't train your fingers to be shorter or longer, so these can be used as static parameters. Finger strength is knowledge from other independent studies and averaged, so still objectively determined. Most importantly though, improved speed is the wishful result of the purpose of optimization. Therefore overall typing speed is not, cannot be a factor in determining the effort grid.

As for my effort grid, the latest one is quite favorable to top row. So is my BEAKL theory which barely penalizes the top row keys right above home keys (except pinky, naturally). I even made the BEAKL Stretch layout that proves stretching up 1 and 2 rows can still result in good layout.

The same professor /document states alphabetic layout has no advantage over QWERTY after training. Yet neglect to mention that half of QWERTY is still in original alphabet order. Thus half of the layout can still be further improved. (which is Colemak et al.)

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 26, 2017, 07:00:06 AM »
Speed typing over unnatural speeds (I. E. For high scores ) is largely irrelevant. Pros like court reporters use shortcuts and macros to achieve over 200 wpm. They don't type full words if they can use shortcuts.

But of real concern is to learn touch typing so it becomes second nature, automatic. It's easier to lose your train of thought when you have to concentrate on hunting for keys.

The fact researchers cant see beyond Dvorak means they haven't done much real research. If they find Dvorak (which is almost 100 years old) only 10% better, then newer layouts should easily be 20 to 50 % improvement.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 26, 2017, 06:12:50 AM »
QWERTY lesson plan:

First lesson -- home row :
Code: [Select]
asdf jkl; asdf fdfdf fafs fafa asdf ;lkj kjkj jljl j;j; asdf jkl; fjfj dfdf dsds klkl sasa l;l; fafa j;j; fsfs fdfd fdfd sd sa jkjk jljl j;j; kjkj l;j; fjfj dkdk slsl a;a; asdf jkl; fjfj dkdk slsl a;a; fsfs dada jljl k;k; jkl; fdsa dada fafa jaja kala jkl; kala jfjf kdkd lsls a;a; jkfd klds l;sa jfds fjkl jkl; fdsa asas dfdf jkjk l;l; j;kl fads fdfd sasa jkjk l;l; fjfj dkdk slsl a;a; asdf jkl;
Lmao.  people are suppsed to learn typing with this trash home row. But it's "better" than Dvorak and others.

Dvorak first lesson review:

Code: [Select]
ueoa htns note not tea aset ten hostes hot one ten the uno onto host seat sat eat toe nose east tons sun snot hunt stunt at hats not tost tents sue neon son tune none hot no hue shoes oats hose toes thus notes tons hunt tenth seats teoth hoe nest house test nose ascents oases

now which first lesson do you think will keep people interested in learning to type? The gibberish home row, or sensible home row that produces actual words?

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 26, 2017, 05:46:04 AM »
Measuring layouts is complex, it's composite of many factors. So doubling one factor doesn't directly mean the layout is twice as good or twice as fast. Hence we don't just measure distance to determine the best layout. 

For that matter, it's also erroneous for researchers to assume that speed is ultimate determinant of typing. There's also learning curve, time to reach certain speed, comfort, satisfaction. For these reasons, QWERTY has not unanimously convinced that it's worth keeping; it's the contrary -- QWERTY has been a huge detriment to ergonomics, progress, efficiency.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 26, 2017, 05:33:02 AM »
The most relevant question is "what does one mean by better?" There are many ways to answer, so the context is important.

1. Typing speed, or words per minute. Speed typing is a trained skill and requires lots of dedicated practice to improve and to achieve very high speeds. But it's laughable that they get professionals who only do 50 wpm. I'm not a pro and I used to do 80 wpm on Dvorak over years of casual typing. My first session with BEAKL 9 I reached 60 wpm.

2. Ease of use, learning.

Anecdote. I learned QWERTY in high school and ended the semester with about 30 wpm. After few years topped out at 55. Then learned Dvorak. Reached 60 in a few months, and through many years of usage, topped out at 85 wpm. Learning BEAKL 8, started at 40, but not easy to use. Trying out BEAKL 9 and instantly do 60 wpm.

 The fact most people can't or won't learn to touch type, despite QWERTY being around for over 100 years and now a staple in everybody's daily routine, could be due to unintuitive, inefficient, irrational standard layout that scares people. On the other hand, Dvorak and its descendants (including BEAKL) are much more rational, intuitive, friendly to use. Thus easier, less training to achieve reasonable speed. The article said typists took only 28 days of learning Dvorak to match QWERTY speed; that's pretty amazing and proves effectiveness of a well designed layout.

So I hazard a guess and boldly conjecture that rationally efficiently designed layouts are easier to learn and faster to reach respectable speed. However QWERTY, despite being the grand daddy monopoly, has miserably failed to enable widespread typing skills.

3. Better Sensation. General testimony of those who switched from QWERTY to a better layout, has almost universally reported more Comfort, feeling in control, less frustration, less fatigue.

Hacks / Re: Futuristic city
« on: October 25, 2017, 08:20:22 PM »
Apparently the technology is almost or already there.

Zip-rails could be maglev. Unlike rope zip-lines, which can only move in one direction and from high to low. Zip-rails can go straight and turn left and right, go up and down, start from any height and go up to any height.

Personal propeller should be light-weight, compact, easy to control, and comfortable for long rides. Seat may be preferable.

Attached images similar to my proposal.

Keyboards and Other Interfaces / Re: Einbinder
« on: October 25, 2017, 03:15:18 AM »

One of Harvey Einbinder's layouts. Needs special hardware, so didn't see easy way to load on our current templates.

May give you some ideas for your thumbkey layouts.

Mmm maybe it will work on ErgoDox. Will have a try.

[edit: attached. Does pretty well at English, when measured against layouts from other people (ie not from here).]

Great read that identifies all the problems with standard keyboard.

Layout on the original figure is interesting enough, but still troubling.

Good: Columns splayed radially like the hands. Separate vowel and consonant districts, which many tout as typical for efficient layouts. Four letters on thumbs. Alternative number row, but still not optimized. Thumb cluster seem reasonable.

Questionable?: Shift at the top-middle above the E? [Easier to capitalize thumb keys?] Moves many bottom row keys to outside of the pinky? [Curling's not great, but gotta be better than stretching pinky way out there.]

Questionable if overloading the thumbs are good. The thumb is strong, but not nimble. So not good at stretching too far or moving between keys. I think two common keys per thumb is most practical.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 25, 2017, 02:01:44 AM »
BTW your "generate layout" function doesn't always work, like after editing layouts. Press button, it goes faded, nothing happens.

-- fixed makeImage -- wrong element
-- replaced hardcode of number of layouts with stored variable

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 24, 2017, 06:19:25 AM »
Mind if I replace all "Author" credits in layouts with your name (instead of Amuseum) or do you want to keep it that way?


KLA change log

-- added layouts: CRY, RSTHD, Balanced V, ADORE, X7.1H
-- flexible number of layouts using URL query: ?numlayouts=N ; defaults to 12 if not set
-- BEAKL Opted 4 Ergo Alt : moved the Enter key to thumb (score much better now)
-- modify layouts presets for more variety

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 24, 2017, 04:34:24 AM »
Web search for BEAKL.

First result is newly created page at Deskthority wiki, only after a few hours. Amazing.  ;D
This topic with a thousand posts is several entries below that. Disappointing.  :'(

Should also create wiki page for clp /sc. to Get traction and begin awareness and discussion to rest of keyboard world.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 23, 2017, 02:06:05 PM »
created page about BEAKL on Deskthority wiki:

Web search for BEAKL.

First result is newly created page at Deskthority wiki, only after a few hours. Amazing.  ;D
This topic with a thousand posts is several entries below that. Disappointing.  :'(

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 23, 2017, 12:08:43 PM »
How does that work if home key is on top or bottom row?

Just Ignore missing row.

Am contemplating my own version, I'll probably "cheat" and just predefine which keys on each physical layout are "home block", which makes it quicker to do the calculations.
[edit: Nah. That won't be fair to layouts that shift home in or out from centre]

For the HomeKeys test I have each layout's home keys loaded in the database, and just check if each letter in the word is on a home key, either natively or with shift/altgr as the case may be.

What if shift is not on home key? For home block, what if shift is on pinky, or requires thumb moving around? So this test also exposes flaw of poor placement of modifiers.

Hacks / Futuristic city
« on: October 23, 2017, 11:46:38 AM »
Futuristic city

Aliens invade Earth and enslave humans
Transform cities with future technology
Fast Individual travel for public:
Hi speed overhead rail, you attach to moving platform above you and you slide along the rail; only one person per platform, like zipline. High strong sturdy long Rails connect between distant districts. Arrive to another district in seconds.
Personal propeller to fly anywhere, wear a propeller above you, like personal helicopter. wear on body (not jetpack.) wide Landing Zones around public destinations, like malls. Borrowed for fee.
Fares for these advanced public transit are expensive, poor families cant afford.
Long distant communication. Seamless connection (how?)

Quandary: would you allow to be invaded if they bring future tech that advance, enhance human lifestyle?
Reminds of allowing (communists) invade but they provide tech to your country. Agree to it?

-- Dream 20171023

Actually the latest Firefox has the tool to take a snapshot of anything you see on the webpage. So that would be the simplest method. No coding necessary.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 23, 2017, 06:40:59 AM »

Seelpy 2 Ergolinear ioeatnrsxyuchfwqvpgldmz206546
Colemak arstneio3707

This list shows how pointless, futile the Words@Home-Key test is. Even when layouts proudly claim to fill the home row with the most common letters, it's still just a miniscule drop in the bucket of the total possible words.

As seen on KLATEST, probably the best case for the Words@Home-Key test is 25% for normal corpus (i.e. not like this list of unique words) on a normal layout (i.e. not CLP/SC). That means only about 25% of the words can be typed by the home keys alone. But more likely it's maybe under 15-20%.

In contrast, for the Words@Home-Block test, the optimized layouts can approach 50% of words typed by the home block. You might argue that since the home block has more keys than on the home row, that this proportional increase is a given. However, that is not so when you observe the poor performing layouts.

Ex. Classics Collection
LayoutHome Keys %Home Block %
Colemak 15% 12%
BEAKL 8 14% 50%

Ex. SAT Words
LayoutHome Keys %Home Block %
Colemak 1.2% 5%
BEAKL 8 0.5% 37%

Ex. Phytochemical
LayoutHome Keys %Home Block %
Colemak 5.9% 5%
BEAKL 8 5.5% 31%

We see that Colemak actually loses words when more keys from the home block are used. In other words, more keys in home block did not help this layout at all; in fact, it performs worse when more keys are added. Ironic.

On the flip side, BEAKL 8 reliably allows more words to be typed from the home block proportional to the amount of extra letters gained.

Let's assess what this means. The home block removes the pinky. That means the home block test considers only the strong fingers. Now what do the numbers mean in this context? For BEAKL, 30-50% of the words can be typed with strong fingers only, no pinky involved. On the other hand, for Colemak, only 5-12% of the words don't use the pinky. In other words, we surmise that roughly 88-95% of the words involve the pinky. (Not really true, since the inner index column is not accounted for. But still, the indications don't look too good for Colemak.)

Of course, not all layouts are as bad as Colemak in this regard. Most layouts will be somewhere in between Colemak and BEAKL 8 in these tests. Consequently, the Words@Home-Block test may be another good indication that BEAKL is headed in the right direction to approaching the optimally ergonomic, efficient layouts.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 22, 2017, 11:09:09 PM »
created page about BEAKL on Deskthority wiki:

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 22, 2017, 08:20:02 AM »
CRY layout is interesting. Better at German than English.

further search got this page which has bunch of other layouts (for German, presumably):

on a whim, went to wikipedia to test texts from all the different languages. the results are pretty much the same regardless of language.

1st place is almost always P_RN
followed closely by BEAKL 9/EZ/5/8, usually in this order
right behind is CRY (but does better in Germanic/Nordic langs)

quite astonishing, almost magical, that these same layouts perform top-notch for every language in the world.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 22, 2017, 07:27:37 AM »
Came across this while looking for something else. It  *SEEMS* to be a python version of Opt, with additional bells and whistles.

The PNGs generated are interesting for visualising finger use even better than KLAs heat maps.

CRY layout is interesting. Better at German than English.

further search got this page which has bunch of other layouts (for German, presumably):

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 22, 2017, 06:56:07 AM »
you grabbing this off the canvas, or some other route?

Am asking because may be able to use a different approach in KLE. At present I grab off canvas there, using code found on web.

built-in function:
Code: [Select]
easier to do from KLA. already have huge list of layouts on different physical designs. and easier to swap letters using drag-and-drop.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 22, 2017, 06:12:59 AM »
KLA change log

-- generate PNG image of layout
-- put character and key frequency tables side-by-side
-- added rank to character frequency
-- sort home words, home block words by total descending

Keyboards and Other Interfaces / Re: BEAKL official page
« on: October 21, 2017, 04:05:42 PM »
Cosmetic: use a mono font (code block?), lining up the characters to their matrix positions, for the layout listed below "main layer"


Uploaded images of various layouts and wrote descriptions for each. Click the 'BEAKL Layouts' link.

Keyboards and Other Interfaces / Generating Images of Keyboard Layouts
« on: October 21, 2017, 01:24:07 PM »
In need of fast way to generate keyboard layouts.

Given layout definition (ex. in JSON), this script should generate an image file (in PNG). Preferably executable in a browser.

Solution in KLA:
[Might not work for some browsers. Works in Vivaldi (chrome).]
In Configuration page, choose the layout, then at bottom, see Layout Image, click Generate button. An small image for the current layout appears adjacent. (The same image remains even if you change layout. So you must manually regenerate if you want another image for different layout.) The image can be clicked for direct download (probably to your browser's default download folder; filename will match layout's name), or right click on the image to open browser menu to view the image in new tab.

Hacks / MOVED: One-handed Keyboard Layout
« on: October 21, 2017, 07:29:17 AM »

Hacks / MOVED: PanGalactic Keyboard Layout
« on: October 21, 2017, 07:29:10 AM »

Hacks / MOVED: Balanced Keyboard Layout
« on: October 21, 2017, 07:28:34 AM »

Keyboards and Other Interfaces / BEAKL official page
« on: October 21, 2017, 12:11:04 AM »
created BEAKL official page

To be used as source for wikis, etc. Please comment.

okay to mention your name?

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 20, 2017, 12:51:07 AM »
Thanks :-)
Seelpy disappointed.
X7.1H surprised. Must finish numbers and punc on that layout.

Seelpy does well when capital letters are more prolific; try the academic texts. Most disappointing is actually Colemak. Feeling more and more respect for Arensito; holds up well to new challenges we conjure up.

You have more layouts you want to officially include to the site?

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: October 19, 2017, 11:24:16 PM »
Added Home Block Words to Misc. Page

That's the "workaround" I was thinking of. But can get messy. In fact, while staring at keyboards tonight, I got to wondering if the fingers should move apart from each other up the keyboard (ie from bottom row to top row) as opposed to Received Wisdom that both hands move up to the left. Which would mean the thumbs get to hit the keys in the widening gap in the centre.
Did a mockup and some tests, results were not encouraging, but who knows what Sholes had in mind?

According to my methods, the ANSI qwerty N is chosen over M since it is slightly closer to home key. Perhaps this is why Sholes put the N there instead of at where M is.

Pages: [1] 2 3 4 ... 22