Author Topic: Home row not optimal?  (Read 4737 times)

0 Members and 1 Guest are viewing this topic.

Offline pw

  • Thread Starter
  • Posts: 21
Home row not optimal?
« on: Tue, 26 July 2016, 02:45:07 »
Hello
I've been investigating optimal layouts for column-aligned keypads using simulated annealing, along similar lines as the carpalx site. (I have a truly ergonomic and am considering using an optimal layout).

Most optimisation code builds in the concept of a home row. If you don't do this, what emerges from the optimisation is not a home row but a 'home gap', between two rows, and the result seems to be significantly more optimal in terms of travel distance. So I end up with a design with the lower 2 rows with the most used keys, and the rarer keys relegated to the top row, and/or the middle 2 columns.

Note that this is probably only suitable for columnar keyboards like the ergodox or TE. Also I have not considered the number row; I will be using a separate layer for numbers, and possibly also some punctuation.

eg the last run I did produced the following (middle columns in lower rows reserved for punctuation)

BYLMVQXJKZ
FRST  OIUP
CWND  AEHG


Has anyone heard of this concept before? Have any optimal designs been published?

Offline algernon

  • Posts: 311
  • A tiny mouse, a hacker.
    • Diaries of a Madman
Re: Home row not optimal?
« Reply #1 on: Tue, 26 July 2016, 06:12:24 »
From my experience typing on a tilted/tented ErgoDox, the bottom row is far less convenient to access than the home row, so putting often used symbols like E and H there does not sound like a good idea. On an ErgoDox, home row > upper row > bottom row is my priority when it comes to placing symbols. Whatever is on the bottom row, should not see more use than those on the home or upper row (save a few exceptions).

If I understand you correctly, you rest your fingers not on the home row, but near the gap between the bottom two rows, right? That makes those two rows very easy to reach, indeed, but the upper row becomes significantly harder. For example, on my ErgoDox, if I'd do this, I'd have to move my hands to reach anything on the top row with my index finger, so typing M, V, Q or X would involve moving my hands. With a home row, I can just stretch the fingers, without moving hands to reach the upper row; and I can bend them inwards to reach the bottom one.

With this in mind, if you want to avoid moving your hands, the "home gap" is likely a bad idea.

Offline Pro XKB

  • Posts: 25
Re: Home row not optimal?
« Reply #2 on: Tue, 26 July 2016, 13:37:22 »
I dimly remember similar observations in my own experiments,  however, I cannot reproduce it.  If I set the individual key efforts in standard.cfg of the AdNW optimizer (http://509.ch/opte.htm) to zero,  using mixed German/English layout, I obtain:

9464              52.855 total effort     0.000 positional effort    left right
                   1.081 same finger rp   1.751 shift same finger top  1.8 11.6
  xqöü, gbclßk    68.604 hand alternat.  24.783 shift hand alter. mid 34.3 32.0
  saeyi tdrnfh     1.028 inward/outward  27.864 inward or outward bot 12.4  7.9
  zoä.u pvwmj      9.622 adjacent        30.432 shift adjacent    sum 48.4 51.6
                  9.6 11.3 13.9 13.6 --.- --.- 17.6 10.8 14.3  8.9 Sh  2.7  1.4

which still has a pronounced home row, just a bit less than the optimum with the original configuration:

9                236.897 total effort   187.054 positional effort    left right
                   1.029 same finger rp   6.976 shift same finger top  5.7 10.5
  kuü.ä vgclßz    71.404 hand alternat.  24.118 shift hand alter. mid 36.4 33.8
  hieao dtrnsf     1.796 inward/outward  25.117 inward or outward bot  5.2  8.5
  xyö,q bpwmj      9.262 adjacent        22.116 shift adjacent    sum 47.2 52.8
                  8.4 11.2 14.0 13.7 --.- --.- 17.6 10.8 14.3 10.1 Sh  2.9  1.2

However, there are fairly “good” layouts that are much different, where the home row is the bottom row:

                  52.983 total effort     0.000 positional effort    left right
                   1.029 same finger rp   6.976 shift same finger top  1.4 11.2
  xyöäq gbclßz    71.404 hand alternat.  24.118 shift hand alter. mid  6.5 33.8
  kuü., tdrnfs     1.796 inward/outward  25.117 inward or outward bot 39.3  7.8
  hieoa pvwmj      9.262 adjacent        22.116 shift adjacent    sum 47.2 52.8
                  8.4 11.2 14.0 13.7 --.- --.- 17.6 10.8 14.3 10.1 Sh  2.9  1.2


With a matrix layout, setting the individual key efforts in teck.cfg to zero,

18850             44.215 total effort     0.000 positional effort    left right
                   0.979 same finger rp   0.000 shift same finger top 10.8 12.2
 bkuüqo gvclfz    69.758 hand alternat.  29.616 shift hand alter. mid 32.8 32.0
  hie,a tdrns      1.876 inward/outward  26.813 inward or outward bot  2.4  5.7
  xyöä. pjwmß      9.569 adjacent        22.833 shift adjacent    sum 48.6 51.4
                  7.2 11.2 14.0 13.7  2.6  1.5 16.1 10.8 14.3  8.7 Sh  2.6  1.5

whereas with the normal configuration:

1173             202.898 total effort   162.062 positional effort    left right
                   1.004 same finger rp   0.000 shift same finger top 11.3  6.6
 xzlcgb ä,üufß    69.936 hand alternat.  25.664 shift hand alter. mid 32.0 36.4
  snrtd oaeih      1.705 inward/outward  26.610 inward or outward bot  6.5  3.1
  vmwpj q.öyk      9.640 adjacent        23.878 shift adjacent    sum 51.1 48.9
                  7.8 14.3 10.8 16.8  1.4  2.7 13.7 14.0 11.2  7.3 Sh  1.4  2.7

(note that you can mirror each of these layouts without changing the effort).  Again, a pronounced home row remains.

Offline pw

  • Thread Starter
  • Posts: 21
Re: Home row not optimal?
« Reply #3 on: Wed, 27 July 2016, 23:18:22 »
I'm not necessarily attached to using the bottom two rows, that was just an example I had at the time. Now I am thinking its better to use the gap just above the home row. From this position, the top and bottom rows are 1.5 key widths away. From the home row, the bottom row is distance 1, but the top row is distance 2.

I have to look more closely at why its giving me this result consistently.

If I load one of these home-gap layouts with punctuation in middle rows into the analyser at http://patorjk.com/, using an ergodox layout, it does in fact come out ahead of colemak or dvorak.

What is a reasonable way of calculating total distance anyway? If two fingers on the same hand type two adjacent characters, neither on the home row, then the distance penalty is presumably not doubled? Are fingers best assumed to relax back to the home row if unused, within some decay interval?
« Last Edit: Thu, 28 July 2016, 00:20:58 by pw »

Offline MajorMajor

  • Posts: 88
  • Mechanical Keyboard Enthusiast
    • Coding Supply
Re: Home row not optimal?
« Reply #4 on: Tue, 02 August 2016, 08:02:36 »
You should check out this thread - https://geekhack.org/index.php?topic=24167.0

Supposedly these are the optimal layouts - http://mkweb.bcgsc.ca/carpalx/?full_optimization

You should really consider having "e" on the home row, it's the most used letter in English.
TKL / Clears / Dvorak / Flipped Space for Life / Best Programming Keyboards

Offline tp4tissue

  • * Destiny Supporter
  • Posts: 13566
  • Location: Official Geekhack Public Defender..
  • OmniExpert of: Rice, Top-Ramen, Ergodox, n Females
Re: Home row not optimal?
« Reply #5 on: Fri, 12 August 2016, 18:51:14 »
Optimizing layout has a Major Flaw in that it is based on a pegged Home row,  where in reality, no fast typers would adhere to.

You are not actually attached to that row ,  between each finger movement, there is buffer time to move the opposite hand or necessary finger into place..

As the muscle memories are created,  those penalties are non existent , especially if using the hover wrist technique, where the wrist is not on the wrist-rest..


If the wrist is hovering, given the length of the arm, it is a VERY minimal movement of the upper arm to move the entire hand.



Overall, an optimal layout is vain, because actual average output is well below what's possible in raw transcription speed..


And if Raw transcription speed was the chase,  then chorded keyboards with fewer keys outstrip what's possible on 37key by 200%,




So finding an optimal key path on qwerty style 37 key is a complete waste of time.