Введення дрібних значень без зміни розкладки

Як часто вам доводиться вводити в інтерфейс якої-небудь програми / web-сервісу дробові значення? Якщо часто, то, ймовірно, ви стикалися з неадекватною поведінкою таких полів. Я, наприклад, досить регулярно б'юся чолом про абсолютно тупі форми. Хочете знати, чому введення дробових значень може довести до сказу, і що з цим робити? Ласкаво просимо по кат.
 
 За моїми спостереженнями найчастіше зустрічаються наступні алгоритму їх поведінки:
 
 
     
  • Вгадай, куди натиснути. Такі поля найчастіше зустрічаються в десктопних додатках. Поле строго фільтрує введення будь-яких символів, окрім цифр і десяткового роздільника. Здавалося б, все логічно. Але давайте проведемо експеримент: закрийте очі і спробуйте ввести в таке строго поле десятковий роздільник, натиснувши всього одну кнопку. Вийшло? Ой, не факт! Проблема суворої фільтрації в тому, що користувач: а) не знає, який із двох стандартних десяткових роздільників використовував розробник; б) при введенні цифр може не замислюватися про поточну розкладці клавіатури. В результаті спроба ввести роздільник більш ніж у половині випадків закінчується невдачею. Це не надто критично, якщо потрібно один раз ввести одне значення, але коли вводити дробові числа доводиться регулярно — така поведінка форми стомлює.
  •  
  • Акуратність — передусім. Цей тип більш характерний для web'а. Ввід не фільтрується взагалі, а при спробі зберегти форму відбувається одне з трьох: відображається повідомлення про помилку; полі введення очищається (або повертається попереднє значення); взагалі нічого не відбувається (форма перевіряється в фоновому режимі і її відправка блокується без видимих ​​користувачеві причин). Мабуть, деякі розробники наївно вважають, що користувач завжди знає, що д про лжно вводити в форму.
  •  
  • Ну якось так… Третій тип кострубатих форм періодично зустрічається скрізь. Передбачити їх поведінку практично неможливо. Приміром, в одній непоганий, в общем-то, shareware-програмі для ведення домашньої бухгалтерії при спробі ввести невірний десятковий розділитеся (точніше — при натисканні кнопки з символом роздільника не в поточній розкладці) ціла частина числа безслідно зникає. В іншій (також далеко не безкоштовною) утиліті введення будь-якого символу, відмінного від цифри і очікуваного програмою роздільника, взагалі викликає системне виняток. Нарешті, у одного дуже крупного російського інтернет-магазина введення будь-якого неприпустимого символу призводить до вставки десяткової коми і двох нулів в дробової частини, а введення точки призводить до… вставці десяткової точки.
  •  
 
Загалом, на дворі XXI століття, інтерфейси розвиваються, а таке тривіальних дії, як введення дробових значень, до сих пір є головним болем користувачів. Кілька років тому мені довелося проектувати (і частково кодіть) невелику програмку, для користувачів якої введення дробових значень був повсякденною завданням. Природно, мені не хотілося повторювати варіанти поведінки, описані вище. В результаті недовгих роздумів народився досить простий алгоритм.
 
Отже, що ж робити з дробовими числами? Перш за все, потрібно обов'язково фільтрувати введення. Перевірка при відправці форми — штука хороша, але для користувача набагато зручніше, якщо ввести значення вдається з першого разу, а не після стусана з боку скрипта. Ось мій варіант такого фільтра:
 
 
     
  1. Дозволяємо введення чисел від 0 до 9
  2.  
  3. При натисканні будь кнопки, несучої будь можливий десятковий роздільник в будь розкладці необхідно підмінити відправлений з клавіатури символ так, щоб в поле вводу потрапив правильний десятковий роздільник.
  4.  
  5. блокуємо спробу введення більш ніж одного десяткового роздільника.
  6.  
  7. обмежуємо число знаків у дробовій частині числа, що вводиться в залежності від типу даних, що вводяться.
  8.  
 
Приклад 1 Користувач на російській розкладці послідовно натискає клавіші [1] [2] [3] [б] [4] [5]. Результат у полі введення:
123.45
 
Приклад 2 Користувач на англійській розкладці послідовно натискає клавіші [1] [2] [3] [Shift +?] [4] [5]. Результат у полі введення:
123.45
Результат роботи даного алгоритму дає відмінний (вау-) ефект. Користувачам більше не потрібно думати про розкладці, натискати Shift і гадати, точку або кому прийняв за десятковий розділитеся програміст. Досліди на живих користувачах показали, що після 1-2 тижнів роботи з таким «розумним» полем вводу повернення до звичайних полям викликає ломку і бажання вбити програміста зламати клавіатуру.
 
PS. Чесно кажучи, цей алгоритм настільки простий, що я на 146% впевнений, що такий підхід був використаний уже не раз і не два. Але з незрозумілих причин він не отримав широкого розповсюдження (якщо не вірите, знайдіть найближче поле введення і перевірте його поведінка — майже впевнений, що воно впишеться в один з трьох «кострубатих» алгоритмів, а не в приведений мною «правильний»).
 
PPS. Для тих, хто пише на Delphi або Lazarus приведу посилання на компонент CurrencyEdit, який реалізує даний алгоритм на відповідній мові: Google Code .
 
PPPS. Конкретні приклади не привожу виключно з поваги в авторам відповідних програм. Якщо хто-небудь з читачів Хабра виявить у своєму коді «неправильні» алгоритми і вирішить поміняти їх на «правильні» — подяка від користувачів гарантована.
 
PPPPS. Якось я не зовсім в темі: в HTML-формах в принципі можна фільтрувати введення?

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.