Во время обработки вашего запроса произошла ошибка:
Неверный пароль. Ваш адрес IP временно заблокирован, поскольку количество неудачных попыток входа превысило разумные пределы. Блокировка будет снята автоматически в течение часа.

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

Для создания хорошего пользотельского взаимодействия (юзабилити) необходимо создать юзер-кейсы. Итак рассмотрим поведение такого пользователя как я:

1) Авторизация частоиспользуемым паролем отнимает 2-3 попытки:

1. Ввести пароль с первого раза и правильно.
2. Понять, что он введён не в той раскладке, сменить раскладку и ввести пароль заново. PROFIT?
3. Вариативно можно ещё при вводе ошибитсья

2) Авторизация частоиспользуемым паролем за чужим компьютером - 3-5 попыток

1. Ввести пароль с первого раза и правильно.
2. Понять, что он введён не в той раскладке, сменить раскладку и ввести пароль заново.
3. Заметить что установлен merde пунтосвитчер, который подумал что это слово должно быть введено по-русски, сменить раскладку, ввести пароль.
4. Отключить совсем пунтосвитчер, который упорно настаивает, что ему виднее в какой раскладке я должна вводить пароли. Иногда не настаивает. или вовремя нажать PageBreak.
5. Опять таки можно и очепятаться.

3) Авторизация редкоиспользуемым паролем, на сервисе, где регистрировалась сто лет назад  - over9000 попыток.

Надо подобрать одно из нескольких паролеобразующих названий. Например, если вам нравится пароль "сыр", то пишем его в английской раскладке русскими буквами, вариации будут: "сыр", "сыр123", "какого сыра вам не нравится мой пароль!!!пыщпыщ".  Впрочем, о том, что разработчики, заставляющие пользователей придумывать пароль не менее 6 символов, (с цифрами, знаками пунктуации и иероглифами), должны вариться в отдельном котле — я писала ещё 4 года назад.

Поэтому вот вам правило:
Предоставлять пользователю хотя бы 10 попыток ввода пароля. Затем показывать капчу, для определения восстания скайнета их никто не отменял. Затем давать ещё 10 попыток без капчи. И только уж после этого блочить вход на час.

"Сбербанк никогда не был быстрым и удобным." — Уважаю честность зато!

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

"Удобное управление лицензированием программы" - O'rly?

Должно быть так:

Пару недель назад у Эрика умерла дочь, Ребекка. И то, что происходит дальше, можно назвать коллективным бессознательным.

Насколько мне известно Ребекка любила фиолетовый цвет (#663399 ), и сообщество разработчиков браузеров посовещались и решили увековечить память о ней в спецификации CSS4 разделе цветов. Закрепив имя цвета rebeccapurple за значением #663399.

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

• https://bugzilla.mozilla.org/show_bug.cgi?id=1024642
• http://trac.webkit.org/changeset/170136
• https://connect.microsoft.com/IE/feedback/details/895019/support-beccapurple-as-html-named-color

Правда мнения самого Эрика ещё не спросили, но это мелочи. Любая критика этого решения нынче считается кощунством и осквернением могил.

Лично я не против добавления очередного непонятного имени цвета. Их и так много, с подробным списком можно ознакомиться на сайте Эрика. Меня интересует этическая сторона вопроса. Если бы умер кто-то из близких мне людей и его имя было бы в списке colornames, меня бы использования любого colorname печалило каждый раз. Т.е. в случае Эрика - каждый день.

Такие дела.

А пока вот вам поняшка. Всем Ы!

• Script-injected "async scripts" considered harmful - igvita.com
• PageSpeed Insights
• the script defer attribute ✩ Mozilla Hacks – the Web developer blog
• JavaScript: Defer Execution - with the defer attribute of the script element
• Очерёдность событий и синхронизация в JavaScript
• Погружение в темные воды загрузки скриптов / Хабрахабр
• Параллельная загрузка JavaScript и CSS без блокирования парсинга страницы / Хабрахабр
• Can I use... Support tables for script defer
• Issue: script[defer] doesn't work in IE<=9
• HTML5's async Script Attribute
• 4.12 Scripting — HTML Standard
• javascript - load and execute order of scripts - Stack Overflow

Самый клёвый вариант - дублировать дату ещё и в ЧПУ (как например в этом блоге). Если в чпу по каким-то причинам нельзя, то хотя бы краткую надпись внизу или вверху новости. Временной контекст - важная штука. Даже неитральные новости типа "Скоро мы откроем новый филиал..." или "В будущем я бы хотела изучить ..." привязаны ко времени, если смотреть на них через год или два.

В новости обязательно писать год, даже если вы думаете что новость актуальна только сейчас. Я просто десятки раз сталкивалась с ситуацией когда публикуют только день и месяц. Это особенно раздражает в новостях о веб-технологиях, типа "вышла новая  версия PHP4" или "СSS свойства которые поддерживают современные браузеры (FF3.6, Chrome 10, Opera 11)" - напишите блин год! Напоминает старый анекдот "Где я? К чёрту подробности в каком я городе?".

Отдельных лучей недоброты служат даты в виде "суббота", или "5 недель назад" - я ещё доверяю датам типа "Вчера" или "Сегодня" - но лучше пишите рядом дату в правильном формате.

Ещё, пользуясь случаем, хочу напомнить про статью Лебедева § 129. Новости на неновостных сайтах - она также актуальна и поныне.

P.S. Жалко, но cghub.com прикрыли.

Сегодня небольшая заметка о linux. Название статьи по английски, т.к. мало ли кто из гугла будет искать, я лично ничего похожего не нашла.

Задача, у вас есть файлы, вида

• 1.jpg
• 2.jpg
• 20.jpg
• 3.jpg
• 30.jpg

и т.п. (в моём случае файлы пользовательской базы данных онлайн-игры, но не важно). Гораздо проще с ними работать когда они в правильном порядке

• 1.jpg
• 2.jpg
• 3.jpg
• 20.jpg
• 30.jpg

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

                #if 0 
 	1350	    /* case insensitive sort files in "a1 a2 a10" order */ 
 	1351	    result.create_key_for_filename = str_utf8_create_key_for_filename; 
 	1352	#else 
 	1353	    /* case insensitive sort files in "a1 a10 a2" order */ 
 	1354	    result.create_key_for_filename = str_utf8_create_key; 
 	1355	#endif 

Я не сильна в программировании на C, но думается мне что это условие if(false){ do somehting} =)

Ну что ж, я скачала сырцы MC отсюда - Sources of Midnight commander - http://ftp.midnight-commander.org/

и в файле mc-4.8.12/lib/strutil/strutilutf8.c нашла уже более годный кусок:

#ifdef MC__USE_STR_UTF8_CREATE_KEY_FOR_FILENAME
    /* case insensitive sort files in "a1 a2 a10" order */
    result.create_key_for_filename = str_utf8_create_key_for_filename;
#else
    /* case insensitive sort files in "a1 a10 a2" order */
    result.create_key_for_filename = str_utf8_create_key;
#endif

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

In the file config.h I've just added:
#define MC__USE_STR_UTF8_CREATE_KEY_FOR_FILENAME 1

Для компиляции мне пришлось установить пакеты

yum install glibc2-devel slang-devel

далее

./configure
make
make install

В Fedora пакет установится в /usr/local/bin/mc

Чтобы файлы сортировались как положено - вы должны выключить флажок Учёт регистра в  настройках сортировки.

For using good numeric sorting you should uncheck "Use sensitive sort" (so it became insensitive) in the sort dialog.

Всем чмоки!

P.S. Кто там пытался блог хакать - отпишись в гостевую, интересно ж. Ругаться не буду. Я целый час следила за твоими попытками =)

"Блин... а мужики-то не знают" - подумала я, и вспомнила, что действительно не писала о том как я сделала автодополнение адреса средствами карт Яндекса!

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

 В отличии от системы Кладр - у Яндекса есть несколько преимуществ:

• Он абсолютно совместим (по написанию имён улиц и т.п) с системой Яндекс.Карт =) - чего нельзя сказать про Кладр.
• Поиск сразу ранжируется по близости к нужному региону. (параметр ll в скрипте).
• Он ощутимо быстрее.
• Не нужны никакие api-key, им можно пользоваться бесплатно (что не запрещено - то разрешено).

В качестве источника данных я использую адрес:

http://suggest-maps.yandex.ru/suggest-geo?callback=show_suggestion&_=1302005670080&lang=ru-RU&ll=37.617671%2C55.755768&spn=2.399139%2C0.624969&highlight=1&fullpath=1&sep=1&search_type=all&part=часть адреса

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

Готовый (почти) яваскрипт - тут http://kolomenka.ru/js/suggest_map_adress.js - пример действия в корзине этого сайта http://kolomenka.ru/cart/ - только сперва что-нибудь положить в корзину нужно.

Напомню что в код также нужно добавить некоторые стили:

/* opensearch js*/
#opensearch_input {font:11px Tahoma,sans-serif;/*padding-left:5px;*/}
#search_suggestion {z-index: 10; border: 1px solid gray; margin:0;list-style:none;padding:0; border-radius:3px;background:#fffffa;background:-moz-linear-gradient(top, #fffffa 0%,#f8f8f0 100%);}
#search_suggestion li {/*position:relative; */margin:0; padding:3px 90px 3px 7px; font:11px Tahoma,sans-serif;}
#search_suggestion i {position:absolute; right:0px;padding:1px 7px;}
#search_suggestion li.active {background:#fff0e8;text-decoration:underline;}
#search_suggestion li a {color: black; text-decoration:none;}
#search_suggestion li a:hover {color: #ff4000;text-decoration:underline;}
.item_price {background:transparent;border:none;}
/* opensearch js*/

Буду рада если кому-то поможет. На Хабре у меня аккаунта нет - но буду рада если вы перепишете эту статью там от своего имени и более подробно.

Странно, что на Хабре я не нашла этой новости. Сегодня компания RedHat официально объявила о замене пакета MySQL на MariaDB в качестве пакета стандартной СУБД для веб-разработчиков:

• http://www.itwire.com/business-it-news/open-source/60292-red-hat-ditches-mysql-switches-to-mariadb

А годом ранее, использовать MariaDB начал community проект Fedora. Пока использовали в качестве теста, оставляя приоритетным пакет mysql, однако в 19й версии главным будет именно пакет mariadb, а mysql будет выкладываться под названием community-mysql:

• http://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB

MariaDB в Википедии

Фонд Викимедия пару месяцев назад так же заявил о переходе на использование Марии в качестве бд. Пока для английской и немецкой версии википедии и ряда связанных проектов:

• https://blog.wikimedia.org/2013/04/22/wikipedia-adopts-mariadb/

MariaDB в Мозилле

Три недели назад обновляли сайт поддержки мозиллы с mysql 5.1 на mariadb 5.5, правда не без косяков, но они были связаны с переходом с 5.1 на 5.5.

• https://blog.mozilla.org/it/2013/05/30/upgrading-support-mozilla-org-databases/

MySQL, MariaDB - в чем разница?

Многие из вас наверное в курсе что пять лет назад компанию MySQL купила компания Sun, а два года назад компанию Sun купила компания Oracle. Они как-то плохо её развивали, и делали всякие enterprise версии. Главный разработчик Michael Widenius (Monty) создатель MySQL, движка MyISAM и кучи всего - взял всех главных разработчиков и свалил в опенсорс. И они начали переписывать код так чтобы всё было в несколько раз быстрее и оптимизированней. Поэтому-то Фёдора с 17го релиза включала mariadb как альтернативную бд. В 19й версии они совсем заменят миску на марию. Мы с коллегами поглядели тесты, прониклись и решили попробовать уже сейчас.

Структура самих баз полностью идентична (читай совместима) - разные только сами программы. Подробнее можете почитать на офицальном сайте - https://mariadb.org. Мария должна (как и грядущая mysql 5.6) совсем не снижать производительности при большой нагрузке.

Для Fedora (и в будущем redhat и centos) система установки через yum очень простая - просто останавливаете Apache и Mysql, удаляете миску (php_mysql тоже удаляется по зависимостям), и ставите марию (и снова php_mysql).

• Steps to replace MySQL with the new MariaDB for testing purposes in Fedora 17 and 18

Для фёдоры она есть в официальном репозитории начиная с 17й версии: http://mirror.yandex.ru/fedora/linux/updates/17/i386/, есть также и "родные" сборки для неё
http://mirror.timeweb.ru/mariadb/mariadb-5.5.31/yum/fedora17-x86/rpms/
https://downloads.mariadb.org/mariadb/repositories/ - собственно у них для всего есть свои сборки.

Новшества

• https://kb.askmonty.org/en/user-statistics/ - модуль сбора статистики от Google - уже встроен в Марию, теперь ничего не нужно патчить. =)
• Thread pool in MariaDB 5.5 - AskMonty KnowledgeBase - умное управление потоками в Марии. Кстати thread_pool появится и в MySQL только в версии 5.6, его там преподносят как мегафичу см. http://dev.mysql.com/tech-resources/articles/mysql-thread-pool.html с очень красивыми графиками.

Совместимость и быстродействие

• MariaDB versus MySQL - Compatibility - AskMonty KnowledgeBase
• MariaDB-5.3 optimizer benchmark « The MariaDB Blog
• Benchmark « The MariaDB Blog

Интересные факты

Создатель этих СУБД (Monty) называл их так в честь своих детей. MySQL - он так назвал в честь дочери My, MariaDB - в честь соответственно Maria и ещё он сделал движок MaxDB назвав соответственно в честь сына. Компания Oracle название mysql оставило себе, так что проект пришлось переименовать. Вместо MyISAM (который тоже в честь My) - он сделал новый движок Aria - который вроде будет очень быстрый. Сначала назвал Maria - но потом подумал что будет много путанницы. В общем объявил конкурс на название и победило Aria 

Вот уже пару недель как наш сервер использует MariaDB 5.5.31 в качестве основной СУБД. Да, да, и этот блог тоже =). (Кстати мы используем фёдору и центос на наших серверах). Полёт отличный. По грубым прикидкам скорость исполнения "медленных" запросов возрасла в 5-10 раз, быстрых запросов в 7-9 раз. Я уже предварительно договорилась с крупным хостинг-провайдером, чтобы они сообщили о результатах внедрения.

Здравствуйте дорогие читатели, жаль что почти полгода не писала никаких статей, а эту статью нужно было написать год назад, я всё не знала как за неё сесть. Наверное статья так бы никогда и не увидела свет, если бы мой друг и коллега mr.troll, не написал её за меня.Тема для меня является одной из самых важных. Речь пойдёт о текстовых полях ввода, а вы знаете как трепетно я отношусь к всевозможным формам, например: «Мастерство авторизации», «Основные ошибки проектирования процесса авторизации», «Пользователь важен для вас? Просто дайте ему зарегистрироваться», «Комментарии open_id». Статью можно считать гостевым постом, поскольку я давно приглашаю кого-нибудь написать свою статью в моём блоге. Надеюсь вам понравится. Итак, слово автору.

ваша Moony.

История проблемы

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

Здравствуйте читатели милого блога Usabili.ru,
Вы наверное знаете а таком атрибуте тега <input> как placeholder. Это такая небольшая подсказочка к текстовому полю ввода (включая пароли и textarea), которая  отображается там до тех пор, пока пользователь не активировал этот input. Такую же штуку, но по старинке на яваскриптах и label'ах ребята из Яндекса делают в своих интерфейсах, например yandex.ru,  http://mail.yandex.com/ и т.п. Сейчас у двух браузеров: Оперы (пока не перешла на вебкит) и IE (9-10) абсолютно правильная реализация данного атрибута, т.е. текст подсказки необходимо сразу прятать, как только пользователь передал фокус в поле ввода (кликнул на него например). Так вот, нынешняя тенденция поведения браузеров — не является удобным для пользователя, уже почти год вебкит не убирает текстовую подсказку по клику, т.е она убирается только тогда когда пользователь начал печатать текст. Я считаю что это поведение смущает пользователя, поскольку  естественным является печать в поле в котором нет текста. Печать в поле в котором текст уже есть, и который не удаляется (через delete или backspace) — очень негативно сказывается на UX.

Данное поведение вебкита — изначально противоречило спецификации, однако из-за него Хикси (Ян Хигсон, единоличный и ответственный редактор html5) разрешил оба варианта — см http://lists.w3.org/Archives/Public/public-html-diffs/2011Oct/0174.html . Я связывался с ним по поводу его решения, увы он сказал что спецификация лишь отражает поведение браузеров, и это все вопросы юзабилити должны решать вендоры браузеров. Правильное поведение сейчас есть у Оперы (Presto) и MSIE 9 и даже в новом IE10.
Не правильное поведение сейчас у Хрома (и многих вебкитовых браузеров) и Файрфокса, который так же не предупреждая изменил его в 16й версии.

Плюсы и минусы нового поведения placeholder

- Пользователь не может отличить placeholder и предустановленное value. Цвет placeholder - наследуется напрямую от input. Поэтому если вы изменили цвет текста для input цвет value и placeholder будут одинаковый. По умолчанию в некоторых браузерах placeholder светлее, однако нельзя сделать его всегда светлее, ибо при другом цвете фона лучше использовать тот цвет который задал пользователь для input.
- Пользователь не уверен, кликнул ли он в поле ввода. Что особенно трудно сказать на тач-устройствах.
- Пользователь может попытаться удалить текст в поле ввода - и это не получится ни клавишу delete ни через backspace

+ Пользователь знает какой плейсхолдер используется в поле ввода, даже кликнув на него (но перед тем как начать печатать). На мой взгляд это сомнительный плюс, только если у пользователя после клика наступил склероз и он реально забыл что же было в поле ввода. Хотя многие видные люди не хотят ориентироваться на "достаточно умных" пользователей, я полагаю что распространённым поведением пользователя - является смотреть куда он тыкает мышкой. Для пользователей которые не смотрят куда они тыкают - априори не возможно сделать качественный интерфейс.
+ Пользователь знает какой плейсхолдер используется, если поле ввода имеет автофокус (пример mail.yandex.com ). Это тоже очень сомнительный плюс. Поскольку по правилам юзабилити - плейсхолдер конечно должен использоваться для описания поле ввода, но не должен использоваться как единственное описание. Так же в случае со связкой логин/пароль - автофокус на поле логина (скрывающий подсказку что первое поле логин) - может быть очевидным для пользователей которые привыкли что на сайтах авторизация через поля логин/пароль, а так же абсолютно очевидна для пользователей которые уже использовали эту форму входа. Вообще автофокус - это единственный и редкий случай где не скрывание текста подсказки хоть как-то оправдано.

Подробнее

О том почему критически важно чтобы подсказка убиралась по клику, а не при вводе текста я подробно писал в трекере мозиллы https://bugzilla.mozilla.org/show_bug.cgi?id=673873#c57 — тут несколько моих комментариев, ну и https://bugzilla.mozilla.org/show_bug.cgi?id=758996 тоже можно глянуть. Если кратко, основная проблема такая: Когда пользователь кликает на поле ввода и placeholder пропадает, он думает: "О. Тут был placeholder". Когда пользователь кликает на поле и placeholder остаётся видимым, он думает: "Что это? Это placeholder или value? Могу ли я печатать текст или сначала нужно удалить то что в поле ввода?". и т.п. Пока я добился от мозиллы настройки dom.placeholder.show_on_focus однако это лишь частичное решение. Как вебмастер мне приходится использовать такую конструкцию:

input:focus:-moz-placeholder {color:transparent;}
input:focus::-webkit-input-placeholder {color:transparent;}
input:-moz-placeholder {font-style:italic;color:#ccc;}
input::-webkit-input-placeholder {font-style:italic;color:#ccc;}
/*  Замечу — свойства вебкита и мозиллы не группируются между собой! */

А в будущем вместо псевдокласса :-moz-placeholder (для старых версий фф) нужно будет писать ещё и псевдоэлемент ::-moz-placeholder. и т.п.

Далее небольшой перевод моих комментариев из багзиллы фф:

Hixie изменил "И" на "И/ИЛИ", и браузер-вендоры стали бездумно реализовывать такое поведение. Разве так можно? часть "И" никто не отменял.

По мне, так у нового поведения серьезная проблема с UX. Быть такого не может, чтобы кому-либо было удобно начинать печатать в поле, уже содержащем текст! Разве я могу предвидеть, что текст магическим образом исчезнет, стоит начать печатать? Замещаемый текст нельзя удалить ни клавишей Delete, ни сочетанием Ctrl+A, Backspace. От него вообще нельзя избавить никоим образом, кроме как начать печатать.

Хотите пример поля с текстом в фокусе, который замещается при начале ввода? Это mcedit (linux Midnight Commander). При открытии поискового диалога, в поле запроса уже находится последнее использованное ключевое слово. И если начнете вводить в это поле текст, это слово поведет себя, как замещающийся текст. Но если не начнете, — оно произведет поиск по ключевому слову, а не по пустой строке! Поэтому это не placeholder - это предопределённое значение (predefined value).

Хотите ещё? Далеко ходить не надо, в Windows просто нажмите Win+R, и вы получите диалоговое окно Run, в котором отображена последняя выбранная в нем команда – если вы начнете печатать, она, ясное дело, удалится, потому что это был выделенный текст, но если не начнете печатать ­­– выполнена будет последняя команда.

Как пользователю различить, то ли это замещаемый текст, то ли предопределённое значение? Единственный метод – поставить курсор!

Таким образом, разве может пользователь при работе с браузером ожидать, что поле, которое ведет себя как с предопределенным значением при установке курсора, будет обработана как пустая строка?  Раньше всё было просто: если после установки курсора строка становится пустой – то в форму отправится пустая строка.

Вы когда-нибудь  опробовали это поведение на мобильных устройствах, таких, как небольшие устройства на Android, в которых с трудом различим текстовый курсор? Там вы не сможете быть уверенными, что попадете, куда хотите.

По мне, так вы сломали всю функциональность замещаемого текста. Единственный способ – имитировать его java-скриптом, как мы делали лет десять назад. И как http://mail.yandex.com/ делает ныне.

И ради чего? Ради пользователей, которые могут забыть замещаемый текст сразу после того, как кликнули на поле для ввода? Так, что ли?

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

Если у поля ввода с замещаемым текстом есть автофокус – замечательно. Если нет – веб-мастеру следует поместить пометку вне поля ввода. Опять же смотрите http://mail.yandex.com/, там автофокус на поле ввода. Если пользователь недостаточно сообразителен, чтобы понять, что это поле для логина, он уберет курсор и прочитает, и в следующий раз уже будет в курсе, для чего это поле. Но текст в поле с курсором будет напрягать его при каждом посещении! И ничего с этим не поделать. Почему бы не показывать замещаемый текст только для автоматически наводящегося курсора, раз уж так необходимо?

Примените следующий код и попытайтесь ввести значение поля:

<form><input type="text" required placeholder="Something"></form>

Это может заставить понервничать даже меня! Оно заявляет мне, что поле пусто – но, эй! – в нем установлен курсор и, я могу поклясться Мозилле, что вижу в нем текст!

Почему не делают никаких UX ревью? Старое доброе правило юзабилити гласит: «Когда достаточно места, и метка для поля ввода важна – используй <label> вне поля ввода вместо placeholder; используй <label>, когда много полей для ввода. Но если есть только одиночная форма поиска, или пара полей логин/пароль, или что-либо столь же очевидное для пользователя – можешь использовать замещаемый текст.» Таким образом,  я полагаю, что атрибут замещаемого текста используется только в том случае, если пользователь может догадаться о его содержании (ie8 вообще не способен его отображать). Получается,  программисты мозиллы считают, что замещаемый текст всегда настолько важен, что должен пользователь должен видеть его даже после клика?! Я не верю, что пользователь может забыть его сразу после клика.

Вот мой основной вопрос: если у вас есть работающий код, зачем его менять? Если у вас есть код, работающий ХОРОШО и всех устраивающий, то зачем его менять?

Может кто-нибудь будет любезен и выскажет личное недовольство старым поведением?  И тем самым дать мне причину?

Славно, что этот баг не будет подтвержден в Gnome по причинам, которые я описал выше.

https://bugzilla.gnome.org/show_bug.cgi?id=667502 - Хорошо для Gnome.

 
Пользователя гораздо больше смущает ситуация, когда он попал курсором в поле и больше не видит подсказки, которая была в поле. Когда он увидит её, прочтёт и поймёт, что писать — она изсчезнет. Это поведение, к примеру, идёт сквозь все интерфейсы системы Mac OS X.

Я считаю это очень правильным решением. Это не баг, это хорошая идея.

Если вы с этим не согласны, вы вольны сделать тот самый фикс в CSS ваших проектов. Но на мой взгляд, вы только запутаете его. А пока обратите на плейсхолдер в адресном и поисковом полях интерфейса Оперы — подсказки в них не исчезают при установке курсора.

Пруф того что в IE10 плейсхолдер специально убирается по клику можно посмотреть тут:

• http://msdn.microsoft.com/en-us/library/ie/hh673544%28v=vs.85%29.aspx
• http://msdn.microsoft.com/en-us/library/ie/hh772942%28v=vs.85%29.aspx
• http://ie.microsoft.com/testdrive/HTML5/Forms/
• Скриншот из IE10

везде пишут "Placeholder text is visible until focus is placed in the element." и т.п.

А вот список связанных багов в FF:

• 673873 – display placeholder when focusing an empty input
• 843284 – placeholder should disappear when text input is clicked on platforms where that is expected
• 758996 – placeholder should disappear when text input is clicked
• 807613 – Option to choose if placeholder should disappear when text input has focus
• 843284 – placeholder should disappear when text input is clicked on platforms where that is expected

P.S. Moony: Статья была написана вообще-то полгода назад. Но перечитать несколько раз и выложить её руки дошли только сегодня. Сорри. Надеюсь вам интересна проблема с placeholder.

Под катом вы можете также посмотреть переписку с Хикси:

23.06.12  Alex Troll <troll@2s.ru>  кому: Ian

Hello Ian,
I'm web developer and usabilist, and your reason for bug 14567
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14567 is quite
unexpected for me.
6 months ago, you do this change in specification:
http://html5.org/tools/web-apps-tracker?from=6781&to=6782
In fact - you allow the placeholder text remain after clicking
(focusing) to input. For my opinion it was a mistake, and now I will
try to argument it.

I did some check. I check native OSes behavior.
In Windows XP (that is quite popular in Russia [31%], instead of
MacOS[1%]) placeholder has it's old behavior. I noticed that in IE8
search field (that use native windows api). I noticed that in latest
"Safari for windows" search field.
In Windows 7 - Safari also have it's old behavior. But Windows 7 has
search field in the "Start menu", and it has autofocus and
placeholder. But this is a hack, if you click it - the autofocus
disappear. If you press Ctrl+A - it also disappear.
I can't check it in Android 4, but Android 2.3.8 has its old good behavior.
In Linux, Gnome refused to implement this behavior
https://bugzilla.gnome.org/show_bug.cgi?id=667502

Now I tell you what is not the placeholder examples. I have example
for a field that has a text on focus, which replaced on typing. It is
mcedit (Linux Midnight Commander). After you open a search dialog the
search field already have a last used keyword. And if you start typing
it behaves as placeholder. But if you don't - it start searching by
the last keyword, not for the empty string!
Another example is in windows, just press Win+R and you have the Run
dialog where you have your last command, selected in it - if you start
typing it obviously deleted, because it was selected text, but if you
don't - last command be executed. This is not placeholders, this is
selected predefined values.

And few weeks ago, it was adopted by Mozilla, so in nightly Firefox
the new  placeholder behavior is appeared. (And that's when I noticed
it).
https://bugzilla.mozilla.org/show_bug.cgi?id=673873
So, lets argue. First and main assumption that I have - is that "the
user knows where he clicking". This is the main concept of usability.
If the user doesn't look where he click (a link, an image, or the
input text with placeholder) then it's impossible to make it good and
usable. If user look but don't understand it - it is not his fault, it
is web developer fault.
Now placeholder looks very similar to input predefined value, in user
point of view. How can user distinguish whether it is a placeholder,
or a predefined value? The only true method is by focus them! The MAIN
difference was that the placeholder must disappear after clicking on
it. There is no way that it can be convenient to somebody to start
typing in field that already has the text! How can I expect that the
text is magically disappear if I start typing? The placeholder text
now can't be deleted by "delete" key, it can't be deleted by "Ctrl+A,
Backspace" combo. It can't be delete at all, except me start typing.
The simple old usability rule is said "When you have enough space and
the input label is important - use <label> outside of input, instead
of placeholder, use labels then you have many inputs at form. But if
is's like search form with single text-input, or login/password, or
anything when user can easily guess it - you can make placeholder". So
I assume that placeholder attribute is only used then user can guess
it (ie8 can't show it at all). Are you assume that placeholder is
always important enough that user must see it even after click?! I
can't believe that user can forgot it after click.
For me, you broke the whole functionality of placeholder. The only way
is to emulate it by javascript, like we did decade ago. Like
http://mail.yandex.com/ is doing today. (Yandex is the major Russian
search engine, like Google).
And what for? For those users who forgot placeholder text right after
they click to input field? Isn't it?

Next, about combination placeholder and autofocus.
If the input with placeholder has autofocus - great. It is how
webmaster want it. If not - webmaster should place label outside of
input. See http://mail.yandex.com/ again - it has autofocus input. If
user not smart enough to determine that it is login field - he will
unfocus and read, and in second time he will already know what it is.
But the text in focused field will stress him every time! It can't be
helped. Why not to show placeholder only with autofocused focus if it
so matter?
Execute the code like this and try to submit field:
<form><input type="text" required placeholder="Something"></

form>
It can stress even me! It tell me that the field is empty, but hei, it
has focus and I swear to Mozilla I see the text in here!

In Mozilla bug discussion I asked a question,  who personally want the
new behavior, or who is complaining with old behavior? No one
answered.

When IE6-8 browsers are outdated and I finally got the opportunity to
use nice placeholder attribute, I was happy like a child. But now it
looks like many web-developers should return to javascript "onclick"
solution. I told my friends and coworkers about the new behavior and
no one liked it.

Please reconsider your decision. This is very important for me, and my
coworkers.

Yours respectfully, Alex.

09.10.12 Ian Hickson <ian@hixie.ch> кому: Alex

On Sat, 23 Jun 2012, Alex Troll wrote:
>
> I'm web developer and usabilist, and your reason for bug 14567
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14567 is quite
> unexpected for me.
>
> 6 months ago, you do this change in specification:
> http://html5.org/tools/web-apps-tracker?from=6781&to=6782
> In fact - you allow the placeholder text remain after clicking
> (focusing) to input. For my opinion it was a mistake, and now I will
> try to argument it.

It's _allowed_, but it's not required. In general, we try not to disallow
any particular user interface; it's up to browser vendors to do what they
think is the best for users.

> Now I tell you what is not the placeholder examples. I have example
> for a field that has a text on focus, which replaced on typing. It is
> mcedit (Linux Midnight Commander). After you open a search dialog the
> search field already have a last used keyword. And if you start typing
> it behaves as placeholder. But if you don't - it start searching by
> the last keyword, not for the empty string!

That's more like having a default value that's selected by default (so
typing replaces it).

> Another example is in windows, just press Win+R and you have the Run
> dialog where you have your last command, selected in it - if you start
> typing it obviously deleted, because it was selected text, but if you
> don't - last command be executed. This is not placeholders, this is
> selected predefined values.

Right.

> Now placeholder looks very similar to input predefined value, in user
> point of view. How can user distinguish whether it is a placeholder,
> or a predefined value? The only true method is by focus them!

Or looking at the colour, typically.

> If the input with placeholder has autofocus - great. It is how
> webmaster want it. If not - webmaster should place label outside of
> input. See http://mail.yandex.com/ again - it has autofocus input. If
> user not smart enough to determine that it is login field - he will
> unfocus and read, and in second time he will already know what it is.

I'm not sure everyone would agree that we should design UIs on the
assumption that users are "smart enough". :-)

But in any case, as noted above, this is up to the browser vendors; the
spec doesn't define the user interface, it just tries to allow all
interfaces that would be compatible with the Web.

09.10.12  Alex Troll <troll@2s.ru> кому: Ian

 

Thanks for the reply, Ian.
IMHO, it must be web-developers who decide whether placeholder should
be visible or not for their users, not only browser vendors. And
actually many web-developers disagree with browser vendors.
see the comments from when Mozilla implemented this in nightly
https://bugzilla.mozilla.org/show_bug.cgi?id=673873

Actually the problem, is that web-developers do not know how to change
the current behavior.

The current solution is:

<style type="text/css">
input:focus:-moz-placeholder {color:transparent;}
input:focus::-webkit-input-placeholder {color:transparent;}
</style>

When you change "input" style rule, it change input:placeholder style
rule too, so in many sites you cant see by color if it is placeholder
or value visible.
So, i now must have something like this, in my stylesheets:

input:-moz-placeholder {font-style:italic;color:#ccc;}
input::-webkit-input-placeholder {font-style:italic;color:#ccc;}

This is usability issue. May be html web-standards should not describe
usability, indeed.
But anyway, very thank you for your reply.

15.12.12 Ian Hickson <ian@hixie.ch> кому: Alex

On Tue, 9 Oct 2012, Alex Troll wrote:
>
> IMHO, it must be web-developers who decide whether placeholder should be
> visible or not for their users, not only browser vendors. And actually
> many web-developers disagree with browser vendors. see the comments from
> when Mozilla implemented this in nightly
> https://bugzilla.mozilla.org/show_bug.cgi?id=673873

The theory (which may or may not be matched in this instance by reality,
but there's not much I can do about that) is that the user agents are the
best representatives of the users, not the Web authors. If the user agents
are wrong about how something should be, then one of them will recognise
that and fix the behaviour, and then users will flock to that browser. In
any case, the browser vendors aren't likely to change just because the
spec said so. And thus the spec defers to the user agents for such things.

> Actually the problem, is that web-developers do not know how to change
> the current behavior.
>
> The current solution is:
> <style type="text/css">
>       input:focus:-moz-placeholder {color:transparent;}
>       input:focus::-webkit-input-placeholder {color:transparent;}
> </style>
>
> When you change "input" style rule, it change input:placeholder style
> rule too, so in many sites you cant see by color if it is placeholder
> or value visible.
> So, i now must have something like this, in my stylesheets:
>
> input:-moz-placeholder {font-style:italic;color:#ccc;}
> input::-webkit-input-placeholder {font-style:italic;color:#ccc;}
>
> This is usability issue.

Yeah, that's an issue. We are working on a long-term fix for this (Web
Components), which once deployed will let you have much finer control over
form controls and other complex elements' renderings.

Как белорусские веб-студии отвечают на запросы клиентов

Мы устроили небольшую проверочку самочувствия  обычного клиента, который собирается заказать разработку самого обычного сайта. Оказалось не таким уж  простым делом выбрать подходящую веб-студию и получить добросовестный и адекватный  ответ на письмо. Нами взяты  44 компании из топа Яндекса по запросу “создание сайта” в регионе “Минск” и из рейтинга marketing.by на 2011 год:

• 3 софт – http://3soft.by/
• Abiatec – http://abiatec.by/
• Agente – http://agente.ru/
• AMG –     http://amg.by/
• Декарт – http://dekart.org/
• Freecoder – http://freecoder.by/
• Иквадарт – http://iquadart.by/
• ITlab – http://itlab.by/
• Masterlink – http://masterlink.by/
• Megagroup – http://megagroup.by/
• Прыдума – http://priduma.by/
• Просто Сайт – http://prostosait.by/
• Red Graphic – http://rg.by/
• Rusakov – http://rusakov.by/
• Tanix – http://tanix.by/
• Ваш сайт – http://vashsait.by/uslugi/sozdanie-sajtov.html
• Webremake – http://webremake.by/
• 3 media – http://www.3media.by/sites
• ArtisMedia – http://www.artismedia.by/
• ЦИМ – http://www.cim.by/
• CSFactory – http://www.csfactory.ru/
• Дизайн-студия Борового – http://www.db.by/
• Altgraphic – http://www.altgraphic.by/
• Студия Дмитрия Кравцова – http://www.dk.by/
• Flexbl – http://www.flexbl.by/
• InfodayMedia – http://www.infodaymedia.com/
• Intelico – http://www.intelico.su/
• Dewpoint – http://www.dewpoint.by/
• Интернет-Маркетинг – http://www.internet-marketing.by/
• Web group – http://www.iweb.by/
• Джей Лаб – http://www.jl.by/
• Каспер системс – http://www.kasper.by/
• Lepshey – http://www.lepshey.ru/
• Медиа Лайн – http://www.medialine.by/
• Новый Сайт – http://www.newsite.by/
• Nineseven – http://www.nineseven.by/
• Orange label – http://www.orangelabel.ru/
• Prolab – http://www.prolab.by/
• Reactive – http://www.reactive.by/
• Site Development – http://www.sid.by/
• Webcom Media – http://www.webcom-media.by/
• Северный завод – http://www.zavod.by/
• Zmedia – http://zmedia.by/
• Астроним – http://www.astronim.com/

После чего на ящик электронной почты или через форму обратной связи каждой из компаний был отправлен один и тот же запрос на выполнение услуг. Представляем его вашему вниманию:

Здравствуйте.

Необходима разработка интернет-магазина. Хотим похожий сайт как http://www.mylo.by/
Только не очень нравится дизайн

Необходимо:
- нужен полностью дизайн
- стандартный каталог товаров с категориями и поиском
- возможность делать скидки на товары
- отсылка писем при изменении статуса заказа (принят, отправлен, закрыт)
- возможность выбирать опции внутри товара (выбрать при заказе цвет, размер)
- выгрузка в эксель и 1с
- чтобы в админке могли работать несколько пользователей с правами доступа
- кабинет покупателя с историей заказов и накоплением скидки в зависимости от покупок
- возможность человеку выбрать в подарок товар при заказе на определенную сумму.
Сколько будет стоить сделать такой магазин? За сколько это вообще реально сделать?
Расскажите, пожалуйста, как будет вообще происходить процесс разработки сайта у вас в компании.
Делали ли вы уже похожие сайты? Хотели бы посмотреть на примеры.
Спасибо.

с уважением …

Мы старались сделать текст письма и запросы в нём  максимально приближенными к возможным требованиям  среднестатистического пользователя.

Результаты оказались, мягко говоря, удивительными. Общий процент ответов на наше письмо составил всего 56% от общего числа компаний. Причём в первые сутки  ответ поступил не от всех, а только от 18 компаний, что составило 69% от общего числа откликнувшихся на призыв о помощи. К тому же, к концу первой недели ответы прислали не все, а только 24 подопытных. Отметим и такой факт, что ящик электронной почты одной из компаний был забит настолько, что дважды отправленное в разные дни  письмо дважды  возвратилось  назад, а ещё одна компания отписывается вежливыми автоматическими  сообщениями, не несущими в себе никакой полезной информации, кроме уверенности клиента, что письмо дошло до адресата. Дальнейших действий со стороны сотрудников компании мы не увидели.

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

Далее предоставляем статистику ответов по пунктам и требованиям нашего письма:

1.Примерную цену назвали 20 веб-студий.

2. Фактически отказалась от работы 1 веб-студия.

3. Фактически отказались от выполнения части функционала 2 веб-студии.

4. Потребовали личного общения 3 веб-студии.

5. Не работал сайт, форма обратной связи и почта у 6 веб-студий.

6. Предоставили бриф 3 веб-студии.

7. Ответили на вопрос о процессе разработки 11 веб-студий.

8. Привели по нашей просьбе примеры работ 15 веб-студий.

9. Написали повторное письмо, после того как не получили отклика от нас –  2 веб-студии.

10. Прислала коммерческое предложение 1 веб-студия.

11. Озвучили сроки 15 веб-студий.

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

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

Мы отдаём себе отчёт, что ценовые предложения, предоставленные компаниями, представляют лишь примерные ориентиры.

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

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

В честь дня рождения блога - завтра статья про плейсхолдеры!

Так же в списке статей — и на самой странице статьи везде будет указано имя автора. (и предположительно аватар).

Я обещаю что вернусь к написанию статей в ближайшее время.

1) В файрфоксе вкладки можно прикреплять, тогда вкладка будет считаться "App tab", будет всегда прикреплена слева иметь приоритет выполнения скриптов такой же как активная вкладка. (В неактивных вкладках различные анимации и т.п. будут приостанавливаться). Но главную интересную фишку, я нашла недавно. Прикреплённые вкладки, например gmail могут мигать, оповещая пользователя об изменениях на странице. Мигает вкладка в том случае — если у данной страницы меняется title. Это легко проверить следующим кодом:

<script>
    // for firefox glowing pinned tab
    // window.setInterval  (function  (){document.title=Math.random  ();},500);
</script>

2) В случае с <input type="number">, если вы сами хотите оформить стрелочки инпута — движки webkit позволяют их отключать. Используйте вот такой код:

input::-webkit-outer-spin-button,
input::-webkit-inner-spin-button {
    /* display: none; <- Crashes Chrome on hover */
    -webkit-appearance: none;
    margin: 0; /* <-- Apparently some margin are still there even though it's hidden */
}

Хочу специально заметить что в случае полей ввода для цифр — не желательно использовать input type="text", так как на мобильных устройствах для этих полей будет показываться текстовая клавиатура, вместо числовой.

3) Firefox в 17й версии будет поддерживать крупные иконки сайтов в адресной строке, что не удивительно с появлением ретины. https://wiki.mozilla.org/Improve_display_of_location_bar_results. По ссылке есть макет концепта
 

Пока этого нет в nightly, но надеюсь скоро появится. Так что можете заранее начать переделывать иконки своих сайтов, если хочется =). Будьте первыми. Надеюсь другие браузеры так же будут использовать большие иконки в своём UI.

Замечу что это касается только favicon.ico. Для айпадика например вы можете задавать большие иконки, но для совершенно других целей.

With Apple's formatting (rounded corners, reflective shine)

<link rel="apple-touch-icon" href="somepath/image.png" />

Without reflective shine

<link rel="apple-touch-icon-precomposed" href="somepath/image.png" />

Ещё интересное про иконки:

• http://ru-webdev.livejournal.com/3212027.html
• http://artgorbunov.ru/bb/soviet/20120116/

4) Ни для кого не секрет какой тормозной плагин скайпа к браузерам, который подсвечивает телефоны на странице. Он перехватывает все изменения DOM в поисках номера, чем заметно тормозит скрипты, и портит дизайн страницы. В Firefox этот плагин в чёрном списке (надеюсь что приложила к этому руку). Тем не менее, где-то мелькала новость что плагин на конкретном сайте вебмастер может отключить добавив следующий метатег.: (подробнее тут)

<meta name="SKYPE_TOOLBAR" content="SKYPE_TOOLBAR_PARSER_COMPATIBLE" />
<meta content="telephone=no" name="format-detection">