Как рассчитать идеальную раскладку клавиатуры для программистов?

Я думаю о создании новой раскладки клавиатуры для программирования. Сейчас я в основном программирую на HTML, JavaScript / jQuery / CoffeeScript, CSS / LESS / SASS, хотя я могу в скором времени заняться написанием сценариев оболочки и RegEx, возможно, через LUA, C ++ и Java через несколько лет. Я хочу получить научное подтверждение размещения ключа. У меня есть идеи / требования, некоторые изобрели я сам, некоторые взяты или получены от других:

• Почти все ключи могут быть переставлены
  • ВОЗВРАТ , Левый SHIFT , Левый КОНТРОЛЬ , ПРОБЕЛ и TAB должны остаться, но все остальные, включая цифры, символы и клавиши перемещения, открыты для перемещения
  • Может быть оптимальным будет оставить zxcv & perhhaps s, чтобы остаться на месте, из-за распространенных привычек Отменить / Вырезать / Копировать / Вставить / Сохранить :)
  • Клавиша DELETE может быть перемещена туда, где находится CAPS LOCK :)
  • Маловероятно, чтобы совпадающие скобки, как () {} [] <>, стояли рядом друг с другом; Смотри ниже
• Единственный точный способ ИМХО подсчитать использование ключа - это регистрация по ключам , а не подсчет ключей по файлам:
  • Большая часть «программирования» - это отправка электронных писем, публикация на форумах, твиттер, сообщения об ошибках, веб-серфинг и т. Д.
  • Я считаю, что большая часть использования клавиатуры - это «движение»; вкладки между полями, страница вниз, перемещение курсоров и т. д. Они не фиксируются выходными данными файла
  • Многие редакторы используют автозаполнение и макросы, поэтому закрывающие разделители:)}]> могут печататься не так часто, как открыватели, поэтому точными будут только файлы регистрации ключей и не парсинга.

Итак, мои вопросы:

1. Что такое безопасные программные кейлоггеры с открытым исходным кодом, которые не будут загружать файлы, если вы сами не отправите отдельный файл? Я бы предпочел НЕ собирать имена и пароли для входа в систему, не только для безопасности, но и потому, что это может бросить мой анализ ИМХО.
2. Какие программы могут быть использованы на стороне клиента для перехвата подсчета отдельных и пар ключей? Или как лучше всего его построить?
3. Где лучше всего найти добровольцев, чтобы помочь?

Лучшее исследование на данный момент: 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

ТИА!

Используйте программу типа WhatPulse, чтобы записать, какие клавиши были нажаты и сколько раз.

После запроса в IRC-сети FreeNode о том, как собрать ключевые частоты, пользователь привел меня к этому:

1. Получите ваш текст, например, программу (ы), и скопируйте их.
2. Перейти на http://type.trmnl.org/
3. Под кнопками обязательно снимите флажок «Автозапуск с содержимым буфера обмена при вставке».
4. Затем вставьте вашу программу в текстовое поле.
5. Нажмите Cntrl + Shift + K, чтобы открыть консоль.
6. Введите count_digraphs()и нажмите Enter.

Результаты читаются следующим образом: "ar" 7 17 10 "ra"это означает, что «ar» нажимали 7 раз, «ra» нажимали 10 раз и все вместе «ar» и «ra» нажимали 17 раз вместе.

Ключи для перемещения в редакторах чаще всего адаптированы для максимально эффективного использования с QWERTY, и поэтому их, несомненно, потребуется перераспределить, если вы измените раскладку клавиш и захотите оптимальное размещение всего, к чему вы стремитесь. Например, в Vim кнопки HJKL используются по определенным причинам с QWERTY, и, скорее всего, их необходимо будет переназначить обратно в то же место после изменения карты ключей.

Я имею в виду, что вам не очень поможет отслеживать движение и редактирование клавиш и использовать их в качестве основы для нового макета, так как они легко реконфигурируемы (в любом редакторе стоит соль, и так как мы говорим о программисте layout, мы, скорее всего, говорим о Vim или Emacs), не должен мешать размещению буквенных клавиш и уже оптимизирован (опять же: мы не говорим о Notepad).

Вы пытаетесь решить проблему, которая является неэффективным способом повышения производительности , особенно для программиста , ** imho **. Было бы гораздо больше эффекта, если бы вы просто больше узнали об инструментах (еще раз: вероятно, Vim / Emacs). Вы обнаружите, что при написании символов тратится все меньше и меньше времени, а больше (но более эффективно) тратится на автозаполнение, автоматическую пометку, авто-отступ, быстрый поиск определения функций и т. Д. Клавиши чтобы сделать все это уже адаптированы для обеспечения эффективности, а большой прирост скорости приходит просто со знакомостью. Таким образом , я утверждаю , что другая раскладка клавиатуры прямо на сравнительно губительна для производительности , так как у вас уже есть многолет QWERTY упражнений. Если бы на QWERTY было потрачено столько же времени на аналитическое обучение, сколько люди, которые переключают раскладки, проводят на Dvorak, они также заметили бы повышение скорости. Скорость приходит с явным обучением.

Если бы вы были копирайтером / переводчиком / автором / и т. Д., Кто-то, кто на самом деле тратит свое время на работу с буквальным значением клавиш, то может помочь другой макет. Для программиста лучшим советом обычно является по крайней мере получить английскую раскладку клавиатуры, поскольку идиомы программирования были сформированы ими и их расположением клавиш (на моей локальной раскладке клавиш @$[]{}~все позади AltGr, что довольно неоптимально).

tldr: Dvorak / Colemak / [следующая «лучшая вещь после нарезанного хлеба»] (возможно) решает проблему только для тех, кто вводит много текущего текста на определенном языке (чаще всего английском). Для программирования необходимые ключи не подлежат тому же ограничению, что и литеральный язык, и, таким образом, они уже оптимизированы для своих целей (которые не просто «пишут так быстро, как вы можете»; они больше строятся на логических операциях. См. Vim). Я считаю, что время, потраченное на изучение альтернативных макетов, и путаница, которая наверняка возникает снова и снова, определенно не стоят усилий в большинстве случаев (не только ваше собственное замешательство; другие, которые садятся за тот же терминал, который вы использовали в последний раз, бросят вещи у вас), в том числе и у программиста.