November 2, 2006

Клавиатурный буффер

Просто зло вселенское.

Нужно, допустим, убить файл. Выскакивает диалог: "Do you really whant to remove folder Xyz? [Yes] [No]". Жмем [Yes]. Тут система начинает что-то делать, но диалог не исчезает, и вообще на экране ничего не происходит. Что сделает нормальный человек? Нажмет [Yes] еще-раз. Прикинем, что на кнопку [Yes] он нажимал нажатием клавиши (Enter например). В таком случае, благодаря клавиатурному буфферу, следующий диалог типа "Folder Xyz contains important files. Are you really sure? [Yes] [No]" имеет все шансы получить утвердительный ответ, хотя юзер этого диалога еще не видел. И может даже не увидит.

На мобильниках и всяких других девайсах, из-за их небольшой скорости их работы, таких ситуаций у меня возникает море, особенно когда торопишься чего-то сделать. А именно на портативных девайсах необходима наибольшая терпимость к случайным ошибочным действиям пользователя, изз-за неидеальных условий их применения (в автобусе, например).

Лечится эта беда не так уж и сложно, достаточно очищать буфер клавиатуры после того, как на экране появился запрос к вводу информации юзером (диалог например), и только после этого реагировать на пользовательский ввод. Ясное дело, что даже самый медленный мобильник сделает это быстрее, чем пользователь сообразит, что именно ему нужно вводить.

Зато есть места, где без такого буффера не обойтись - это edit-box, например. Там обязательно важно, чтобы все пользовательские нажатия учитывались. Потому-что там важнейшую роль играет последовательность ввода, и независимость этой последовательности от информации на экране. Здесь никакой обратной связи нет - как минимум 50% пользователей не смотрят на экран вообще с того момента, как они начали печатать текст, и до того, как закончат предложение. Однако здесь работает звуковое оповещение. При наборе символов в поле ввода чисел, например, в системных edit-box'ах windows раздается звуковой сигнал.