Почему так мало модальных редакторов, которые не являются vi*?

Раннее программное обеспечение часто было модальным, но юзабилити в какой-то момент повернуло в сторону от этого стиля.

Редакторы на основе VI-это полная загадка - они единственные реально выжившие члены этого порядка программного обеспечения.

Режимы являются no-no в удобстве использования и дизайне взаимодействия, потому что мы, люди, - непостоянные млекопитающие, которым нельзя доверять, чтобы помнить, в каком режиме находится приложение.

Если вы думаете, что вы находитесь в одном "mode", когда вы на самом деле находитесь в другом, тогда могут возникнуть все виды плохого. То, что вы считаете серией безвредных нажатий клавиш, может (в неправильном режиме) вызвать неограниченную катастрофу. Это называется a "mode error".

Чтобы узнать больше, найдите термин "modeless" (и "usability")

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

Хм... может быть, в этом нет особой необходимости, учитывая, что Vi/Vim в значительной степени доступен везде и получил всю модальную вещь правильно? :)

Я думаю, что это потому, что vi (и ему подобные) уже занимает экологическую нишу модальных редакторов.

Число людей, которые предпочитают модальный режим и еще не были привлечены к vi, вероятно, равно 0, поэтому гипотетический конкурент vi должен быть настолько велик, чтобы заставить значительное число пользователей vi переключиться. Это маловероятно. Стоимость переключения редакторов огромна, и vi-s, вероятно, уже так хороши, как модальные Редакторы идут. Ну, может быть, значительный прорыв мог бы улучшить их, но я нахожу это маловероятным.

@Leon: отличный ответ.

@dbr: модальное редактирование-это то, к чему требуется некоторое время, чтобы привыкнуть. Если бы вы создали новый редактор, который соответствует этой парадигме, как бы вы улучшили VI/VIM/Emacs? Я думаю, что это отчасти и есть ответ на вопрос. Получить его "right" достаточно сложно, конкурировать с такими, как VI/VIM/Emacs, было бы чрезвычайно трудно - большинство людей, которые используют эти редакторы, являются поклонниками "die hard", и вам придется дать им убедительную причину перейти в другой редактор. Те люди, которые уже не используют их, скорее всего, останутся в немодальном редакторе. IMHO конечно ;)

Модальные редакторы имеют огромное преимущество перед сенсорными машинистками, что вы можете перемещаться по экрану, не отрывая рук от главного ряда. Мои запястья болят только тогда, когда я делаю то, что требует от меня постоянного перемещения руки с клавиатуры на мышь или клавиши со стрелками и обратно.

Помните, что Блокнот-это модальный редактор!

Чтобы увидеть это, попробуйте ввести E , D, I , T ; теперь попробуйте ввести Alt , E , D , I , T . Во втором случае клавиша Alt активирует "menu mode", поэтому результаты будут другими. - ОП-люди, похоже, справляются с этим.

(Да,это функция Windows, а не конкретно Блокнота. Я думаю, что это плохая функция, потому что легко нажать Alt по ошибке, и я не думаю, что вы можете отключить его.)

VIM и emacs имеют примерно столько же смысла в дизайне пользовательского интерфейса, сколько qwerty. Теперь у нас есть доступные современные компьютерные оптимизированные ключевые макеты (см. макет colemak и проект carpalx); это только вопрос времени, когда кто-то сделает то же самое для текстовых редакторов.

Я считаю, что Eclipse имеет привязки Vi и существует Visual Studio plugin/extension, тоже (который называется Vi-Emu или что-то в этом роде).

Я думаю, что ответ на этот вопрос заключается в том, что на самом деле существует довольно много модальных текстовых редакторов, которые не являются форками vi/vim., однако все они используют привязки ключей vi . Vi пользователи получают привязки ключей в свою мышечную память, поэтому повторное изучение другого набора Привязок ключей будет очень трудно, поэтому никто не будет создавать другой набор Привязок ключей.

Но множество различных редакторов заново реализовали привязки ключей vi с нуля. Просто посмотрите на этот вопрос о IDEs с привязкой ключей vi . По крайней мере половина ответов-это редакторы, построенные с нуля, которые реализуют привязки ключей vi, а не версии vi embedded.

Хотя на самом деле я не отвечаю на ваш вопрос, раньше существовал способ "modal like" писать по-японски на мобильных телефонах : Первая буква, которую вы нажмете, была согласной, скажем, K, а затем, а затем следующая клавиша, которую вы нажмете, будет иметь роль согласного. (Наличие двух согласных подряд в японском языке невозможно)

Хотя он был главным несколько лет назад, сегодня его используют только те, кто действительно хочет быстро ударить.

Недавно я наткнулся на divascheme-альтернативный набор ключевых Привязок для DrScheme . Это модально, и часть оправдания связана с RSI-специально избегая большого количества скручивания запястья, чтобы ударить Ctrl - Alt - Shift - something -да . Программист провел неофициальный опрос коллег-программистов и обнаружил, что emacs пользователей страдали от большей боли в запястье, чем vi программистов.

Вы можете видеть, как он делает короткую речь на LugRadio Live USA . (Видео представляет собой серию 5-минутных бесед, и я не могу вспомнить, как далеко он находится, извините - если кто-то смотрит его и публикует, что здесь я отредактирую этот пост, чтобы сказать, когда в видео это будет).

Обратите внимание, что я не использовал divascheme.

Стоит отметить, что выживаемость входных моделей vi отчасти объясняется ее принятием в стандарте POSIX, поэтому инвестирование времени в обучение будет означать, что вы гарантированно сможете работать над любой системой, соответствующей этим стандартам. Так что, как и в английском языке, в вездесущности есть сила.

Что касается альтернатив, то я сомневаюсь, что альтернативный редактор моделей выдержит 30-дневный бесплатный пробный период, поэтому по той же причине больше людей ездят на автоматике, чем летают на самолетах.

Изобретение мыши взяло один режим и переместило его на устройство ввода, а контекстные меню взяли другой режим и переместили его на кнопку. Как ни странно, появление сенсорных устройств имело обратный эффект, производя мультимодальные интерфейсы:

• осознанный мультимодальный-прикосновение и речь осознают друг друга и пересекаются

• неосознанный мультимодальный-прикосновение и речь не осознают друг друга и конфликтуют

Традиционные интерфейсы WIMP имеют базовую предпосылку, что информация может поступать в систему и выходить из нее через один канал или поток событий. Этот поток событий может быть в форме ввода (мышь, клавиатура и т.д.), где пользователь вводит данные в систему и ожидает обратной связи в виде вывода (голос, вибрация, визуальный и т.д.), Когда система отвечает. Но канал сохраняет свою уникальность и может обрабатывать информацию из одного источника за раз. Например, в сегодняшнем взаимодействии компьютер игнорирует введенную информацию (с помощью клавиатуры) при нажатии кнопки мыши.

Это очень сильно отличается от мультимодального взаимодействия, когда система имеет несколько потоков событий и каналов и может обрабатывать информацию, поступающую через различные режимы ввода, действующие параллельно, такие как описанные выше. Например, в системе IVR пользователь может вводить текст или говорить, чтобы перемещаться по меню.

Рекомендации

• Руководство по обеспечению специальных возможностей агента пользователя рабочая группа (UAWG): примеры использования интерфейса клавиатуры

• W3C мультимодальный стандарт приносит паутину к большему количеству людей, больше путей

• Следующие шаги для W3C работы над мультимодальными стандартами

• Будущее взаимодействия-мультимодальное

• Помимо мыши и клавиатуры: расширение конструктивных соображений для взаимодействия с визуализацией информации - naturalinfovis_infovis2012.pdf

• Настройка области применения для легких веб-приложений

• Янв. 26, 1983: электронная таблица так же проста, как 1-2-3

• Мультимодальный дизайн: жест, прикосновение и мобильный devices...next большая вещь? / Динамика Опыта