Como calcular o layout de teclado ideal para programadores?

Estou pensando em criar um novo layout de teclado para programação. Agora, eu programa principalmente em HTML, JavaScript / jQuery / CoffeeScript, CSS / LESS / SASS, embora eu possa se interessar por scripts de shell e RegEx em breve, talvez com LUA, C ++ e Java em alguns anos. Quero ter provas científicas das colocações da chave. Tenho idéias / requisitos, alguns me inventaram, outros foram tirados ou derivados de outros:

• Quase todas as chaves podem ser reorganizadas
  • RETURN , SHIFT esquerdo , CONTROL esquerdo , barra de espaço e TAB precisam permanecer, mas todos os outros, incluindo números, símbolos e teclas de movimento, estão abertos para movimentação
  • Pode ser ideal deixar zxcv e talvez s para permanecer no lugar, devido aos hábitos comuns de Desfazer / Cortar / Copiar / Colar / Salvar / Salvar :)
  • Chave DELETE que provavelmente será movida para onde CAPS LOCK está :)
  • É improvável que você mantenha colchetes correspondentes como () {} [] <> próximos um do outro; ver abaixo
• A única maneira precisa do IMHO de contar o uso de chaves é por meio do registro de chaves, e não da contagem de arquivos:
  • Grande parte da "programação" está enviando e-mails, postando em fóruns, twitter, relatórios de bugs, navegação na web etc.
  • Eu acredito que grande parte do uso do teclado é "movimento"; tabulação entre campos, página para baixo, movimentação de cursores etc. Isso não é capturado pelas saídas do arquivo
  • Muitos editores usam macros e preenchimento automático: portanto, os delimitadores próximos:)}]> podem não ser tão freqüentemente digitados quanto os abridores; portanto, apenas os registros de chaves e os arquivos de análise não são precisos.

Então, minhas perguntas:

1. O que são keyloggers de software seguro / de código aberto, que não carregam arquivos, a menos que você mesmo envie um arquivo separado? Eu preferiria NÃO coletar nomes e senhas de logon, não apenas por segurança, mas também porque isso pode gerar o IMHO da minha análise.
2. Quais programas podem ser usados ​​no lado do cliente para digerir contagens de chaves únicas e emparelhadas? Ou como melhor construir um?
3. Onde é melhor encontrar voluntários para ajudar?

Melhor pesquisa até agora: http://www.michaelcapewell.com/projects/keyboard/layout_capewell.htm

http://viralintrospection.wordpress.com/category/technology/keyboard-layouts/

& Wikipedia: Keyboard_layout # Non-QWERTY_keyboards_for_Latin_scripts

TIA!

Use um programa como o WhatPulse para registrar quais teclas são pressionadas e quantas vezes.

Depois de perguntar na rede FreeNode IRC sobre como reunir as principais frequências, um usuário me levou a isso:

1. Obtenha seu texto, como um programa, e copie-o.
2. Vá para http://type.trmnl.org/
3. Sob os botões, desmarque a opção 'iniciar automaticamente com o conteúdo da área de transferência ao colar'
4. Em seguida, cole seu programa na caixa de texto.
5. Pressione Cntrl + Shift + K, que abrirá um console.
6. Digite count_digraphs()e pressione Enter.

Os resultados são lidos assim: o "ar" 7 17 10 "ra"que significa que 'ar' foi pressionado 7 vezes, 'ra' foi pressionado 10 vezes e todos juntos 'ar' e 'ra' foram pressionados 17 vezes juntos

As teclas para movimento nos editores são mais frequentemente adaptadas para se adaptarem ao uso mais eficiente possível com o QWERTY, e certamente precisarão ser remapeadas se você alterar o layout das teclas e desejar o posicionamento ideal de tudo o que se esforça. Por exemplo, no Vim, os botões HJKL são usados ​​por um motivo com o QWERTY e provavelmente precisam ser remapeados novamente para o mesmo local após a modificação do mapa de teclas.

O que quero dizer é que não ajudará muito a rastrear as teclas de movimento e edição e usá-las como base para um novo layout, pois elas são facilmente reconfiguráveis (em qualquer editor que vale a pena, e já que estamos falando sobre a programação de um programador). layout, provavelmente estamos falando do Vim ou do Emacs), não deve interferir no posicionamento das chaves literais e já foram otimizadas (novamente: não estamos falando do bloco de notas).

Você está tentando resolver um problema que é uma maneira ineficiente de produtividade , especialmente para um programador , ** imho **. Haveria um efeito muito maior em simplesmente aprender mais sobre as ferramentas (mais uma vez: provavelmente Vim / Emacs). Você descobrirá que cada vez menos tempo é gasto na criação de caracteres na programação e mais (mas mais eficiente) é gasto na conclusão automática, marcação automática, recuo automático, pesquisas rápidas de definição de função, etc. As teclas para fazer tudo isso já estão adaptados para permitir eficiência, e o grande aumento de velocidade vem simplesmente com a familiaridade. Por isso, argumento que um layout de teclado diferente é comparativamente destrutivo para a produtividade , já que você já tem muitosanos de exercício QWERTY. Se o mesmo tempo de treinamento analítico fosse gasto no QWERTY que as pessoas que trocam de layout gastam em Dvorak, elas também notariam um aumento de velocidade. A velocidade vem com treinamento explícito.

Se você era um redator / tradutor / autor / etc., Alguém que realmente gasta seu tempo trabalhando com o significado literal das teclas, um layout diferente pode ajudar. Para um programador, a melhor dica é geralmente obter pelo menos um layout de teclado em inglês, pois os idiomas de programação foram modelados por eles e pelo posicionamento das teclas (no layout de teclas local, @$[]{}~todos estão atrás do AltGr, o que é bastante insatisfatório).

tldr: Dvorak / Colemak / [a próxima "melhor coisa desde pão fatiado"] (sem dúvida) resolve um problema apenas para aqueles que inserem muito texto corrido em um idioma específico (geralmente inglês). Para programação, as chaves necessárias não foram sujeitas à mesma restrição que a linguagem literal e, portanto, já foram otimizadas para sua finalidade (que não é apenas "escreva o mais rápido que puder"; ela se baseia mais em operações lógicas. Vim). Acredito que o tempo gasto na aprendizagem de layouts alternativos e a confusão que certamente ocorre repetidas vezes não valem o esforço na maioria dos casos (não apenas a sua própria confusão; outros que se sentam no mesmo terminal que você usou pela última vez jogam coisas para você), incluindo muito o programador.