Как стать автором
Обновить

Комментарии 126

интересные у вас всё же примеры)
Грудь — специальная часть женщины

[x]
Попка — специально ориентированная часть женщины)
написал жепку — ставь жепку!
Вкладкой ошибся =)
Ага, тариф «Хреновый» ((=
Хм. в целом всё разумно. Да, я конечно понимаю, что нестандартные элементы — это чаще всего зло. Но в данном случае имеет место ещё и, может, утомляемость того же дизайнера в создании однотипных элементов. Ну например есть ты 5 лет подряд в каждом проекте рисуешь одни и те же элементы — хочется убить всех и себя, но только перестать рисовать их, сделать их по-другому.
Более того, как отделить прогресс, от неудобных элементов. Да, понятно что многие решения проверены годами и являются наиболее оптимальными. Но как в таком случае отделить непривычное и незнакомое пользователям, но потенциально более оптимальное и эффективное решение, имеющее более высокую степень удобства, чем старые, проверенные годами методы.
Для небольших компаний выгодно занимать выжидающую позицию. Ожидать, пока крупные введут новые интерфейсы, время, пока люди привыкнут, а затем уже без особых проблем можно вводить и у себя. Слайдеров раньше тоже практически не было, а сейчас ничего, пользуются где нужно.
Замечательный пример — нестандартная многофункциональная кнопка от Google в его GMail-е. Мне она сразу понравилась, хоть и не совсем привычная для вэба.

Думаю, со временем она появится во многих местах (уже почти придумал, где я могу использовать похожую в своем проекте)
Утомляемость дизайнера не оправдание) Когда дизайнер перестает мыслить здраво, он перестает быть дизайнером. И даже к однотипным элементам в каждом отдельном случае нужен свой подход, т.к. условия их использования в рамках разных проектов постоянно меняются. Их можно бесконечно кантовать, перемещать, выделять и обособлять, в пределах стандартной модели разумеется. А изобретать толковый велосипед, дело достаточно трудное, поэтому заниматься этим без особой необходимости и достаточного запаса времени чаще вредно, чем полезно :)
Часто сталкиваюсь с такой ситуацией, хоть и проектирую GUI для Desktop — приложений. Вот вроде бы хочется вот эту красивую «рюшечку», но понимаю, что она красива для большинства, но на сколько удобно для большинства я не могу сказать. Часто приходится следовать традициям и удобству, тянуть корни интерфейсов большинства часто используемых в повседневной жизне программ, потому что люди уже интуитивно привыкли к ним.
Спасибо за такое исследование, однозначно в закладки, и хочется видеть побольше таких статей с таким конструктивным подходом.
так вы проектируете или «раскрашиваете»?
По возложенным на меня обязанностям, мне приходится и проектировать и реализовывать:). У нас все на всем любят экономить.
мда)
«Цена за ночь» улыбнула


>кириллица запрещена

Вот жеж любят в русскоязычных странах что-то запрещать юзерам. Позитивные и вежливые мессиджи нужно делать. Например, «пожалуйста, только латинские символы». Тоже на конверсию влияет, между прочим.
Абсолютно согласен. С точки зрения психолингвистики, запрещающие и отрицающие словесные конструкции вызывают подсознательное отторжение.
Имхо, еще не помешало бы вывести подсказки на отдельных строчках.
И добавить функцию «сгенерировать пароль»
и убрать поле пароль (высылать на почту, если конечно есть необходимость наличия почты/пароля)
хм, даже меня иногда эта функция пугает. кому нужно, пользуются спец. ПО
Имхо, хорошо бы вывести подсказки на отдельных строчках. Вы же предыдущий коммент читали про «С точки зрения психолингвистики, запрещающие и отрицающие словесные конструкции вызывают подсознательное отторжение.» ;)
Ну на всех по разному действует, в одной зарубежной гостинице на мостике над бассейном на разных языках написано «пожалуйста не прыгайте в бассейн с моста» и только на русском «прыгать с моста запрещено», видимо эмпирическим путем вывели что на нас такой запрет лучше действует:)
особенности языка, в русском много не- и отрицаний.
Прыгал, прыгаю, и буду прыгать.
Особо бесят также запреты снимать на мой фотоаппарат фото/видео в аквапарках.
А еще лучше сделать так, чтобы не пришлось вводить только латинские символы, это же пароль.
Если разрешить одновременный ввод русских и латинских символов, то это, как минимум, приведет к резкому увеличению частоты использования функции «Напомнить пароль». Оно нужно? :)
Последнее время предпочитаю считать, что пользователи в большинстве своем умнее скота. И излишняя забота может дать нежелательный эффект. Поэтому «детские» ограничения нужно все-таки стараться нивелировать. В разумных пределах конечно…

Совсем недавно, стукнулся головой о стену из похожей «заботы», когда интернет-банкинг сказал, что мой пароль может быть длиной от 8 до 12 символов, и ни в коем случае не больше. Тоже наверно подумали, что волю дай — такого напридумывают… В итоге порвали мой шаблон, заставили напрягаться :)
Это ещё что. Когда мне при регистрации на одном сервисе сказали, что у меня e-mail неправильный (буква-собака-домен), я КРАЙНЕ удивился. Правда, напрягаться не стал, просто закрыл страницу.
НЛО прилетело и опубликовало эту надпись здесь
Что-то не понял? А Вы руками функцию «Напомнить пароль» выполняете?
Безусловно. Специально нанятые обезьянки сидят, генерят новые пароли и с извинениями отсылают клиентам.
Ну я так и не понял причины запрещать ввод пароля на любом языке? Обезьянки берут деньги за отправку писем?
Использование более, чем одной раскладки в поле типа password значительно увеличивает количество ошибок при вводе пароля, т.к. по-умолчанию вводимые символы скрыты звездочками. Много ошибок -> раздражение пользователей -> потеря пользователей.
Если хотите использовать несколько раскладок, тогда добавьте динамическую индикацию раскладки рядом с полем.
Что же касается функции «Напомнить пароль», то каждый переход, не ведущий к бизнес-цели проекта — убыточен. Зачем самостоятельно создавать поле для размножения «паразитных» переходов. Нет, если цель состоит в том, чтобы показать страницу с напоминанием пароля как можно большему количеству пользователей, тогда это имеет смысл. Иначе — нет.
>Использование более, чем одной раскладки в поле типа password значительно увеличивает количество ошибок при вводе пароля, т.к. >по-умолчанию вводимые символы скрыты звездочками. Много ошибок -> раздражение пользователей -> потеря пользователей.

Странная логика. Вы говорите о том что человек может забыть переключить раскладку? Ну так он это может забыть сделать в любом случае.

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

С точки зрения юзабилити нет ни каких оснований ограничивать пользователя в его правах. IMHO
Вы придумываете лишние проблемы, вместо того, чтобы просто позволить пользователю вводить все, что ему захочется (не надо считать их идиотами, и тем более не надо их заставлять так себя чувствовать), не скрывать вводимое «звездочками» (см. регистрацию на imobilco.ru), и на крайний случай присылать введенный пароль на указанный ящик, когда он указывается.
Руки чешутся топик об излишней заботе о пользователе написать.
Я бы почитал с удовольствием)
Согласен с тем, что скрывать пароль под звездочками — это издевательство над пользователем. Причем не обоснованное ничем. Пожалуй, соглашусь с Вами, что нужно позволить пользователю использовать такой пароль, какой ему нравится, это будет правильнее всего.
Прятать пароль за звёздочками придумали для того, чтобы его не подсмотрел стоящий на спиной. Открывать его можно, но только в том случае, если пользователь явно указывает, что хочет видеть его в открытом виде. Оставлять поле ввода пароля открытым по умолчанию нельзя ни в коем случае. А то получится как с литресом: заходишь на главную, а там твой сохранённый пароль сияет в открытом виде.
Стоп, «только латинские символы» — не то же самое, что «кириллица запрещена». Скорее всего имелось в виду латиница, цифры, подчеркивания и т.д.
Позабавила контекстная помощь в виде спасательного круга :)
Укорачивание форм, т.е. уменьшение количества заполняемых полей, приводит к тому, что накладываемые на поле лейблы становятся вполне удобными. Мы, проектируя интерфейс «Телентиды» долго спорили на эту тему и, в итоге, пришли к решению, что форма авторизации/регистрации (которые у нас состоят из двух полей — «Логин» и «Пароль») можно спокойно делать с overlayed лейблами.

Жаль, что в статье не рассматривается замена стандартных селектов с небольшим количеством вариантов на псевдо-ссылки, работающие с помощью JS.

P.S. Количество пользователей с выключенным JS, в процентном соотношении, очень близко к нулю, поэтому для таких посетителей разумнее делать уведомления с помощью noscript, нежели не использовать JS в формах.
* формы</strong авторизации и регистрации * — досадная опечатка
Да уж, давно ничего не писал на Хабре. Надеялся, что редактирование комментариев своих когда-нибудь введут, ан нет…
Я не ноль — у меня NoScript включен по умолчанию на неизвестных сайтах.
Бывает лень вносить новый сайт в белый лист.
«Близко к нулю» != «ноль»
Я не говорю про абсолютное отсутствие поддержки работоспособности сайта без JS, но если у пользователя нет желания пользоваться каким-либо сайтом или сервисом — он уйдет, в независимости от того, включен ли у него JS. Обратная ситуация, когда люди выключают параноидальные браузерные плагины на нормальных сайтах без всплывающей рекламы и ненужных скриптов, довольно часто встречается.
> Количество пользователей с выключенным JS, в процентном соотношении, очень близко к нулю, поэтому для таких посетителей разумнее делать уведомления с помощью noscript, нежели не использовать JS в формах.

Подавляющее большинство сайтов, работоспособность которых без js невозможна, даже до NOSCRIPT не снисходят, да отсохнут у их создателей руки, чтобы больше не писали.
завел для себя привычку очень давно. сайт делаю чтобы все без скриптов работало. потом где хочется сделать жаваскриптовые формы вешаю на линки remote=true и скриптами перехватываю. в итоге если включен js то будет с аяксом. если нет то просто переход на страницу. сайт не ломается.
Ни однин справочник о remote ничего не знает. Где почитать?
нигде. это просто в рельсах придумано. в xhtml вы можете в любой тег добавлять свои аттрибуты. ну и делаем a href='/bbb' remote='true' и в скриптах $('a[remote=true]').bind('click', function(){}) и т.д. все это работае в любом браузере.

з.ы. может ошибся с селектором. ща думать лень :)
ну и preventDefault не забыть вызвать чтобы переход по ссылке не прошел.
точнее не remote, а data-remote чтобы еще и валидно для html5 было
Это еще одна сторона проектирования интерфейса и последующего написания кода, так, чтобы если выключен JS все работало как надо, пусть не в том виде.
На самом деле, все правильно, но есть одно «но». В нашей стране рядовой пользователь ГОРАЗДО глупее, и вполне очевидные вещи зачастую не работают. Мне приходится ежедневно сталкиваться с теми, кто вообще первый раз в жизни форму заполняет — так и то проблемы есть при условии, что форма у меня практически вылизана до блеска. И контекстные подсказки тебе, и поля большие, и сократил их до минимума — все мало :-)

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

В общем, к чему я… Мне кажется, в статье не хватает пункта «Знай свою аудиторию». Просто от этого, на мой взгляд, нужно отталкиваться в первую очередь при создании форм.
В базовые обязанности проектировщика интерфейсов априори входит анализ ЦА. Без этого вообще никуда. А для пользователей с нулевым UX нужно дополнительно к текстовым пояснениям делать видеоинструкции по работе с формой.
К счастью, пользователей с полным отсутствием опыта достаточно мало, как минимум они прошли через одноклассников, мэйл.ру и другие крупные сайты. Вот от их интерфейсов и нужно отталкиваться в таких случаях.
Увы, «чайников» очень много :-(
Это становится явно, когда начинаешь работать не с Москвой/Питером, а со всей страной. Мне из таких жоп пишут, что в пору становиться учителем географии.
Не делайте пользователя виноватым в ваших собственных ошибках.
Вы настолько хорошо знакомы с моим опытом, что можете делать подобный выводы? Или просто сказать нечего больше?
Я сужу по вашему комментарию, и тут не в опыте дело совершенно.
Вы судите неправильно и поверхностно. И дело таки ж в опыте, просто он у всех разный.
Со слайдерами, мне кажется, палка слегка перегнута. Это полезный и удобный элемент, просто нужно чувство меры.

Слайдер уместен и полезен для указания даже дискретной величины/диапазона, если:
а) число вариантов относительно велико (а шаг, соответственно, мелкий).
б) величина имеет «естественно ощущаемую» функцию сравнения.

Например:
1. Выберите цвет сумки: [черный, белый, красный, розовый] — слайдер неуместен
2. Выберите тариф: [базовый, премиум, супер] — слайдер неуместен
3. На какую сумму выбираем подарок? [100...100000 рублей] — слайдер в тему
4. Дисковоле пространство: [1..100 Гб] — слайдер в тему

Мне в голову приходят калькуляторы тарифов для облачных хостингов. Обычно там память, диск, процессор нужно выбирать минимум из десятка значений. Представить себе такое поле чекбоксов просто страшно. Выпадающие списки тоже не очень удобны, т.к. не видно пределы. (Речь именно о калькуляторах, когда человек хочет оценить конкретно свои затраты — тарифы сами по себе, конечно, должны быть в таблице.)

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

А упомянутый случай с +8% к конверсии, возможно, объясняется косвенными факторами. В частности, нарисован тот слайдер довольно невнятно, промежуточные значения ощущаются очень плохо.
Безусловно, для перечисленных Вами ситуаций слайдер можно (и даже нужно) использовать. Но на то и голова дана дизайнеру-проектировщику, чтобы думать об уместности тех или иных контролов.

По поводу конверсии на австралийском сайте: то исследование проводил, к сожалению, не я, поэтому говорить что-то о дополнительных факторах, оказывающих влияние на конверсию, не могу. Возможно, дизайн, возможно еще что-то. Тут важен результат и решение руководства портала, принятое на основе этого результата. Кстати, в том исследовании использовалась неплохая такая выборка в 24000 человек.
Яндекс.Маркет решил проблему просто: над слайдером разместил поля ввода:
slider
У Маркета вообще хороший интерфейс, на который во многих случаях можно равняться.
А когда вводишь всё правильно включая капчу, кроме одного поля, а потом тебя кидают взад и говорят — поле-то, мол, неправильно, а капчу надо второй раз ебаться вводить? пидоры!!!
Халтура и некомпетентность отталкивает клиентов не только в веб-разработке, но и в других сферах.
Еще и поле пароля скидывают, особенно при регистрации. А его еще два раза вводить надо. Арррхххх
каптча на большинстве ресурсов стоит не из-за того что надо, а потому что модно. вот и проблемы возникают.
> На что вы обращаете внимание при виде женщины?

В вашем примере два самых популрных варианта-то не учтены. За юзабилити — кол, даже варианта «другое» нет.
Лицо, а что еще?
А ещё человека иногда не по частям оценивают. Этот подход принято обозначать загадочным словом «фигура».
Кто бы написал статью о том, как канонічно реализовывать сложные форм в вебе — например, иерархического типа, с подформами и всё такое…
Делайте по типу десктопных приложений, не ошибетесь. Я имею в виду оконный интерфейс. На самом деле, нужно смотреть конкретную ситуацию, исследовать, проводить тестирования. Универсального решения для таких вещей нет и быть не может.
В том-то и дело, что не всегда получается перенести концепции из мира десктопных приложений на веб-формы… Вернее, можно, конечно — но это получится просто «десктопные формы на веб-странице», а я же больше имел в виду именно применение обычных веб-форм для редактирования сложных данных. Как-то так. А если ещё вспомнить про graceful degradation — вообще голова пухнет.
Для сложных форм стоит озаботится созданием нормального видеотуториала. Если у пользователя нет навыка пользования такой формой, создайте его сами.
За graceful degradation гнаться рентабельно далеко не всегда. Зачастую, дешевле и эффективнее явно указать пользователю минимальные требования для работы с приложением. Хотя, повторюсь, все нужно решать в каждом конкретном случае, универсальных решений нет, увы…
Дайте пример такой формы пожалуйста.
Не делать такое вообще.
Никто не любит сложные интерфейсы. Если в какой-дь монстроподобной системе, которую продают за сотни тысяч долларов, такое себе можно позволить, то в обычном вебе практически нельзя позволять себе делать такие формы. Либо надо предлагать действительно уникальный продукт/услугу.
> Такое расположение заголовка поля приводит к тому, что люди, привыкшие с детства читать сверху вниз, видят сначала пустое текстовое поле, после чего они вынуждены искать дальше пояснение к нему, а затем вернуться обратно к пол

Где вы такие ебанутые интерфейсы нашли
А между прочим такое часто видел я.
Статистические данные из космоса?.. Интересно было бы увидеть источник информации, условия эксперимента. Есть ощущение, что цифры сильно завышены для красного словца:

> следствие неграмотного использования контекстной помощи теряется до 23% пользователей, и снижается лояльность у более, чем 60%
НЛО прилетело и опубликовало эту надпись здесь
Странно наблюдать трендовость Хабра. С легкой подачки перевода статьи Smashing Magazine пошла череда «формочных» постов.
Тоже был с хостерами, Android, Ardulino, Lisp и пр.
Индукция происходит, вот и все :) Какая-то тема наводит на мысль, что неплохо было бы написать статью.
Не припомню статьи про лиспы в Smashing Magazine.
как же достали те идиоты, которые тянут нас в суровый мрачный глупый мир средневекового мс-доса
идите лучше полоть картофель в колхоз, умники!
стандартизация интерфейса — это круто!
вин95 сделала гигантский шаг вперед в этом направлении
а вы своими дурацкими красивостями все возвращаете вспять
тупицы… все, кто поступает — тупицы
в школу им пора, или в университет
кстати, скины для приложений — идиотизм
только медиаплееры по историческим причинам имеют право иметь скин
остальные приложения (включая новомодные 1с 8.0 с кастомным заголовком) на скин права не имеют
надеюсь это прочитают ее создатели и устыдятся своей глупости беспросветной
А мне нравится скин Google Chrome. Я даже поставил тему, которая окна в моем WinXP превратила в сплошные хромы))

По теме:
грамотные люди, оцените, пожалуйста, веб-форму при покупке ICQ-номера

Поля и кнопки в разброс по всему блоку. Мне было бы неудобно.
Невыровненые поля — дикий ужас
Цветочки на фоне — блевотина
Сама форма — говно.
Ага, спасибо за обратную связь)
А если сделать label's над полями ввода будет лучше?
заведите мерчанта лучше (просто кнопка купить без всяких там форм). и пользователем удобнее и вам.
Как минимум нужно:
1) Убрать жуткий фон
2) Вместо «10 цифр без 8 и +7» просто под полем написать пример правильного номера, но с +7, иначе юзер может не врубиться. И на лету проверять правильность и предоставлять относительную свободу в формате ввода.
3) "Ваш что-то там" писать не надо, это и коню ясно, а форму загромождает.
4) Выровнять поля.
5) У обязательных полей просто оставить звездочки.
6) У контактной аськи написать «необязательно», юзеру пофиг что там желательно, если он не захочет указывать он не укажет ее, для него это все равно «необязательно»
7) Убрать звездочку с примечание, иначе юзер может может побежать глазами от поля со звездочкой к примечанию.

Короче форму надо переделать.
Оооо, спасибо большое!
Поработали над ошибками, как сейчас?



Ваш бла-бла решили оставить, так как не всегда клиенты спецы, которые могут даже KDE2 под FreeBSD пропатчить и иногда вводили, например, в поле Ваш текущий ICQ-номер — покупаемый номер.
Конверсия изменилась? Уже 11 дней прошло, первые робкие выводы уже можно делать.
Стали заказывать больше, но и увеличился процент не оплативших счет :( Такое ощущение, что людям нравится заполнять форму, но реально они не хотят покупать :)

P.S. на наших микромасштабах вряд ли можно какие-то выводы делать)
Фраза «стали заказывать больше» здесь ключевая :-)
Осталось понять, почему заполняют, но не оплачивают и вообще всё отлично.
Артемий, залогинтесь.
Даже медиаплеер на имеет права на скин. Имхо.
Но вот Chromium со своим стандартным скином выглядит очень хорошо. Может быть потому что уже привык.
Используйте интерфейсы на ncurses и проблема скинов отпадёт сама собой. Они ещё и непостижимым образом стандартизировались. Сравните, например, ncmpcpp и rtorrent.
Нет. Я за то, чтобы интерфейсы софта были в рамках гайдлайнов Qt.
Но терпимость к скину хромиума и сам не могу объяснить))
Насчет веба, то один из самых приятных мне интерфейсов у 2ip.ru
статья полезна тем людям которые уже что-то понимают в UX… для новичка, который не может осмыслить все это, статья просто испортит специалиста (пусть и начинающего)

к каждому пункту следует добавить монолог из старой рекламы — "-Ты не любишь кошек? -Ты просто не умеешь их готовить."

слайдеры… рассказываете про все слайдеры что можно, а в примере показываете то что вызывает отвращение у большинства. почему не было примера с того же gandi.net/hosting? или еще откуда-нибудь?

обязательные поля… это сейчас привычно звездочки. но с приходом это изменится (браузеры которые понимают required уже сейчас обводят инпут красной рамочкой)

формы с заголовками внутри… тоже спорная вещь. надо уметь готовить :) естественно если форма из 50-ти textarea в которые надо написать по 250+ символов, то вы правы. но если login/password то это верное решение. даже в вашем вариант из примера (3 поля) вполне оправдано использование данных вещей.


disclaimer я не зря написал. Претендую на истинность только в области чисел, полученных в ходе собственных исследований (и то, выборка в 60 человек не очень репрезентативна, конечно же). Все остальное — очень тонкие вещи, зависящие от множества факторов и контекста использования. Именно поэтому и хочется дискуссии, хочется обсуждать, сравнивать с чужим опытом.
60 человек это очень мало. это как меня спросить :) я вот посмотрел на форму где лейблы под полями и запомнил что к чему там (сам я не люблю так делать по нескольким причинам — не люблю форматирование по правой стороне и лейблы не на одной строке с полями). но все таки беглого взгляда на форму хватило чтобы не испугаться и, тем более, не запутаться.
Много воды вокруг очевидных вещей. Но автор прав — мудаку-дизайнеру на заметку. Только мудаки-дизайнеры такие статьи не читают. Им лень. Они заняты «дизайном» веб-форм.
Знаете, если на маленький вопросик на айпаде нажимать неудобно, то навести мышкой, чтобы увидеть всплывающую подсказку на нем просто невозможно.
Мне нравится эта форма:

Заголовок для поля ввода внутри самого поля

По поводу минусов:
Когда пользователь начинает вводить данные в поле, заголовок исчезает. И если пользователь на что-либо отвлечется, вернувшись затем к форме, он не сразу сможет понять, что за поле он заполняет;


Во-первых, часто ли вас отвлекают, когда вы заполняете формы? Заполнение формы минутное дело, скорее всего вначале заполните, потом отвлечетесь. Во-вторых, пусть даже отвлекли, неужели вы уже забыли, какую форму начали заполнять?

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

Случай, где не поленились это не минус.

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

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

# Невозможно использовать такой дизайн форм в случаях, когда заголовки полей состоят более, чем из 2-3 слов;

Это понятно, что если заголовок не влазит в форму. Но такое редко бывает.

JS, используемый для реализации данного дизайна необоснованно усложняет код фронтенда;

А как это влияет на юзабилити?

> Шрифт заполненной формы и незаполненной отличается контрастом. Кому сложно отличить?

Если у клиента нет js — то не отличается.
P.S. Количество пользователей с выключенным JS, в процентном соотношении, очень близко к нулю, поэтому для таких посетителей разумнее делать уведомления с помощью noscript, нежели не использовать JS в формах.


Вот про js-обсуждали
habrahabr.ru/blogs/ui_design_and_usability/112083/#comment_3583525
НЛО прилетело и опубликовало эту надпись здесь
то данное поле мигнет красным


«Мигать» красным в этом мире должны только сирены спец.служб и пожарной тревоги
НЛО прилетело и опубликовало эту надпись здесь

Зачем тут (справа) чекбоксы? Тогда уж радиобаттон наверное.
Чтобы иметь возможность расширить диапазон.
НЛО прилетело и опубликовало эту надпись здесь
«Ты так говоришь, будто это что-то плохое»
Простите, не удержался.
НЛО прилетело и опубликовало эту надпись здесь
Если нельзя выбирать несколько диапазонов, то можно на js, например, реализовать авточек всех предыдущих чекбоксов.
Ну можно и зубы удалять сами знаете через что…
Вот же показали уже хороший вариант, зачем изобретать велосипеды?
Насчёт layered текстбоксов — ИМХО, заголовок надо писать рядом, а в качестве содержимого — серым цветом ПРИМЕР заполнения.
Ну и само собой проставлять их динамически самим js-ом. Т.о. если у человека не будет включен js — то их просто не будет.
На мой взгляд, эта очень хорошая идея во многих случаях станет единственно возможным компромиссом между минимализмом и информативностью.
НЛО прилетело и опубликовало эту надпись здесь
Все охуенно и по теме.

Бесят формы, где кликаешь на поле, а потом думаешь, что же туда вводить.

Плюс в карму.
Интересно, а нет противоречия между первой частью, где говорится и объясняется почему делать метки под строкой ввода неправильно, и последующей, где показано размещение контекстной помощи под строкой ввода? Ведь суть одно и тоже?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории