Введите символы на картинке

С каждым днем разработчики веб-сервисов придумывают все более изощренные методы борьбы со спам-роботами и конкурентами, перекачивающими содержимое с одного веб-портала на другой. Любимое средство защиты — CAPTCHA-тест с картинкой, конечно же.

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

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

Подозреваю, что в какой-то момент у каждого человека может наступить порог отказа от использования веб-сервиса, когда у него слишком долго не получается пройти CAPTCHA-тест. Например, у меня этот порог наступил, когда мне дали ссылку на загрузку файла с известного для любителей халявы сервиса RapidShare. Я был в таком шоке от их теста, что до сих пор с содроганием вспоминаю ту напряженную работу по раглядыванию котов.

Где-то после 7-й попытки расшифровать его я плюнул на скачиваемый файл и пошел делать гимнастику для глаз. Особенно обидно было позже узнать, что этот тест был взломан ботами каким-то обходным путем. Т.е. фактически веб-сервис введением этого теста снизил шансы для человека и одновременно повысил их для другой компьютерной программы.

Теперь у меня есть правило: если я не могу при регистрации пройти CAPTCHA за 3 попытки, то я иду искать другой аналогичный веб-сервис, благо сейчас их очень большой выбор. Да здравствует конкуренция!

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

Настройка или параметры?

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

Вот яркий пример. MS Word с его знаменитыми двумя пунктами меню "Сервис", которые мало того, что являются полными синонимами в сознании пользователя, но еще и расположены рядом.

Пункты "Настройка…" и "Параметры…". Кто их не путал никогда, пусть первым бросит в меня камень.

Я постоянно пользуюсь редактором Word с 1998 г., и, когда мне нужно открыть диалоговое окно конфигурации программы, вместо этого в половине случаев я почему-то попадаю в окно настройки панелей инструментов и клавиатурных комбинаций. Выучить нужную команду не удается, уж слишком они похожи.

Казалось бы, что стоило написать "Настройка команд…" и поместить этот пункт в другую секцию меню "Сервис", или назвать другой пункт "Параметры программы…". Будто в этих названиях разрешено было использовать только одно слово.

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

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

Да? Нет? Отменить? О!

Что мне больше всего нравится в замечательной почтовой программе "TheBat!" (пишется с восклицательным знаком, да), созданной молдавскими ребятами из компании RitLabs?

Конечно же, диалоговое окно, которое появляется при попытке закрытия программы, когда она получает или отправляет почту:

Читать далее…

Про восклицательные знаки

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

То же самое относится и к пользовательскому интерфейсу! Программа не должна быть кричащей истеричкой! Если у вас вместо кнопки "Пуск" будет написано "Пуск!", то мне будет страшно на нее нажимать: кто знает, на какие последствия нажатия вы намекаете этим восклицательным знаком!

Вам не тяжело читать этот пост?!!!

А этот сайт?!!

О пунктах меню

Изучение премудростей дизайна пользовательских интерфейсов я начинал с прочтения отличной книги Джоэля Спольски «Руководство по UI дизайну для программистов». Поскольку там были высказаны очень здравые идеи, я стал постоянным читателем его блога JoelOnSoftware и позднее вступил в сообщество переводчиков.

А недавно Джоэль опубликовал там коротенькую заметку следующего содержания:

Не скрывайте и не выключайте пунктов меню.

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

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

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

Заметка вызвала неоднозначную реакцию на его форуме. Многие разработчики интерфейса посчитали это нецелесообразным, потому что такой подход помогает начинающим пользователям, но вызывает огромное раздражение опытных пользователей. Представьте себе ситуацию, когда вы, не выделив предварительно текст в редакторе Word, случайно нажимаете пункт меню «Правка—Копировать». И вместо того, чтобы проигнорировать действие, которое не может быть выполнено в данном контексте, на экран вываливается диалог с текстом вроде такого: «Команда Копировать недоступна, так как вы предварительно не выделили текст, который надо скопировать». Этот принцип напрямую противоречит главе 6 вышеназванной книги Джоэля, потому что опытные пользователи никогда не читают текстовых сообщений, а от появления блокирующих диалоговых окон могут иногда просто разбить монитор.

Форумчане придумали альтернативное решение: показывать пункты меню отключенными, но оставлять их доступными для нажатия, а при нажатии показывать всплывающую подсказку с пояснением причин отключения. Правда, никто не учел себестоимость реализации такого решения, потому что выключенные стандартными способами пункты меню во всех RAD-системах, которые я знаю, не генерируют событие нажатия. А потому придется «плыть против течения» и городить жуткий дополнительный код для реализации нестандартного затенения неактивных пунктов меню + отслеживания кликов по ним.

На мой взгляд, вместо этого стоит пораскинуть мозгами при проектировании интерфейса и применять подход, предложенный Джоэлем, только в тех случаях, когда предыдущий «жизненный опыт» пользователя не может помочь ему интуитивно определить причину отключении пунктов меню. В 99% случаев пользователи начинают использовать вашу программу только после знакомства с одним или несколькими десктопными приложениями, вроде MS Office. Поэтому базовые операции, которые можно/нельзя провести с различными объектами приложения, им, скорее всего, известны.

При пристальном рассмотрении своего текущего проекта я понял, что уже наполовину это реализовал. В редактор тестов можно вставлять формулы, которые являются OLE-объектами Microsoft Equation. Делается это путем выбора пункта меню «Вставка—Формула». Объект Microsoft Equation не входит в стандартную поставку Windows, а устанавливается на компьютер вместе с пакетом Microsoft Office. Потому вставка формулы невозможна при его отсутствии.

Там где формулу нельзя вставить в принципе (например, когда фокус ввода не находится в редакторах вопросов/ответов), было принято решение блокировать этот пункт меню. А в случае, если формулу вставить можно, но Microsoft Equation не установлен, соответствующий пункт меню не блокируется, и при его нажатии выводится сообщение, поясняющее отсутствие OLE-объекта на компьютере. Без этого неподготовленный пользователь вряд ли сможет проявить интуицию и догадаться, почему формулу вставить нельзя, без прочтения руководства по использованию.

О прогнозах времени

Сегодня захотел я провести обновление своей Windows XP вышедшим недавно Service Pack 3. Ну и заодно обновить DirectX, уж гулять, так гулять. Поставил их в очередь на загрузку.

Замечательная (к тому же совершенно бесплатная) программа Download Master выдала вот такой прогноз:

Скорость ADSL-канала 60 Кбайт/с практически равномерно разделилась между двумя загрузками, и для каждой загрузки был написан свой прогноз времени. Этот прогноз вычисляется динамически по средней скорости, расходуемой на закачку, потому что скорость может колебаться как из-за неравномерной нагрузки на канал, так и из-за перегруженности сервера, с которого качается файл. Так что цифры прогноза слегка скачут, но с этим можно смириться.

Для первой закачки (DirectX) осталось примерно полчаса, для второй (SP3) — 3 часа.

Значит ли это, что я скачаю Service Pack 3 через три часа?
Нет. Он загрузится гораздо раньше.

К сожалению, метод прогнозирования времени Download Master не учитывает тот факт, что при окончании закачки файла меньшего размера (DirectX) полная скорость канала будет в распоряжении второй закачки (SP3). После 30 минут загрузки со скоростью 30 Кбайт/с вторая закачка получит все 60 Кбайт/с и время ее загрузки сократится ровно в 2 раза: 1 ч. 15 мин. против 2 ч. 30 мин.

Итого, время загрузки второго файла составит 1 ч. 45 мин., а не три часа, как запланировал Download Master.

А если загружается 3 файла разного размера? А если 10 файлов? Погрешность прогноза будет только увеличиваться.

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