В Телеграме помимо ссылок на заметки делюсь околодизайнерскими наблюдениями.
В Твиттере помимо ссылок на заметки пишу всякую чушь.
В Тумблере и Же-же есть автоматические трансляции. Если не работает, напишите мне: ilyabirman@ilyabirman.ru.
По РСС и Джейсон-фиду трансляции для автоматических читалок
Я публиковал отзыв Антона Вольных о консультации. После той консультации Антон решил обратиться ко мне за дизайном нового приложения «Совести». А я позвал в помощники Ивана Звягина.
В результате нашей работы получился интерфейс:
Главная идея — вместо форм и условий приложение встречает журналом товаров, которые можно купить в рассрочку по карте «Совесть». Читайте рассказ о проекте.
Миша Танский показал видос своего доклада с 404феста:
Там четыре истории, которые полезно послушать начинающим дизайнерам. Прокомментирую.
Первая история про то, как хотели сделать админку для функции X, а потом догадались, что можно сделать без админки, с текстовым конфигом. Отсутствие админки должно быть как раз решением по умолчанию, а не примером такой ловкости-хитрости. Мне кажется, админками мыслят люди, проработавшие много лет в корпорациях, где количество доступных ресурсов на несколько порядков превосходит то, что они способны переварить. Когда ты работаешь в небольшой команде или вообще над своими проектами, мысль «сделать админку» в подобных ситуациях просто не приходит в голову, это какое-то необъяснимое ничем расточительство. Я до сих пор до конца не понимаю, Мишин слайд «Необходимые объекты дизайна» — это антипример в образовательных целях или они правда всерьёз такое рассматривали.
Кстати, небольшой частный пример на эту тему. Представьте, что вам в форме нужно сделать возможность указать несколько телефонов. Или перечислить несколько наименований товаров при заказе. Многие начинающие дизайнеры любят мастерить конструкции из полей с плюсиком в конце и минусиком возле каждого поля. Потом, когда спрашиваешь: «А как мне поменять местами, сделать третий телефон основным?» они добавляют какие-нибудь кнопки для таскания-сортировки этих полей. А всего-то надо было сразу поставить многострочное текстовое поле и не трахать мозг. В сто раз дешевле, функциональнее, безбажнее, управляемее с клавиатуры.
Просто запомните как принцип: в первую очередь рассматривать решение в виде плейнтекста, а уже потом в виде специально придуманного под задачу интерфейса.
Вторая история — объединение форм входа и регистрации — верный шаг с точки зрения уменьшения «количества интерфейса», но это настолько серьёзный удар по привычкам, что просто так это делать нельзя. Чтобы такое сделать, нужно вообще убрать слова «вход», «регистрация» и вообще изменить парадигму. И, конечно, это рисковано, и не факт, что надо конкретному бизнесу.
Пример подобной смены парадигмы, который приходит мне в голову — это сохранение документов. Долгое время в программах была кнопка «Сохранить» с иконкой дискеты. Время от времени дизайнеры покушались на эту иконку, мол, современные пользователи дискет-то никогда не видели, надо придумать какой-то новый образ. Но дело в том, что даже если пользователь никогда не видел живую дискету, он тысячу раз видел её иконку на кнопке и привык к этой кнопке. И к тому, что это третья кнопка слева тоже привык. Поэтому изменение иконки здесь только навредит, а нормальный шаг в сторону будущего — снятие необходимости в сохранении вообще, как в Гугль-доке.
Третья история про «анду без анду». Типа люди иногда по ошибке делали в приложении Y и просили анду (правильно просили). Но технически реализовать анду было суперсложно (я в это, конечно, не верю, но это сейчас не важно), поэтому перед действием сделали подтверждение. Фишка в том, что вместо текста «Точно сделать? Да / Нет» в окне подтверждения написано «Готово! Завершить / Отменить». Подтверждение вместо анду — нормально как флекс, но, конечно, это плохой интерфейс. И замена одних слов другими в этом ничего не меняет, потому что проблема подтверждений не в словах, в чём легко убедиться, представив, что интерфейс на венгерском.
Любопытно, что чаще всего бывает наоборот: люди, которые ошибаются, просят добавить подтверждение, и только нормальный дизайнер интерфейса знает, что это мало чему поможет, и поэтому настаивает на том, чтобы сделать анду.
На моём курсе как раз в теме «Привычка» мы говорим про бессмысленность подтверждений. Там можно узнать о том, что анду почти всегда намного дешевле в реализации, чем может показаться.
Четвёртая история похожа на первую. Как только Миша рассказал, что люди недозаполняли форму, а потом у них пропадали данные, первый же вопрос в моей голове был — «А чего их в локалсторидж-то не писать»? Я несколько лет назад проходил подобную историю в Эгее, когда думал о том, как не терять недописанные заметки при сбоях интернета. Перед тем, как так и сделать, ребята пытались спроектировать какой-то сложный мир черновиков с горой интерфейса для всего.
Задачи такого рода упрощаются, если изменить своё отношение к ним. Безусловное хранение пользовательских данных — это не фича, требующая проектирования, а обязательное свойство самих элементов интерфейса. Если так об этом думать, то можно заранее на уровне архитектуры системы заложить, например, что каждое поле помнит, что в него вписали, пока это не стёрли.
Возьмите, скажем, эсемески на айфоне. Если написать эсемеску, но не отправить, и вообще выйти из приложения, где будет лежать её текст? Прямо в том поле, где вы его написали! Нет никаких черновиков, не нужно придумывать интерфейс сохранения, восстановления неотправленных эсемесок — ничего этого нет. Просто если ещё раз зайти в диалог с этим же человеком, в поле всё ещё будет вписано то, что было вписано ранее.
Это как в реальном мире. Если я положил книжку на стол, мне не нужно сохранять этот факт, она будет просто там лежать, пока я сам же её не захочу куда-то переместить. Для сохранения данных по умолчанию не нужно никакого интерфейса. Данные сохраняются точно так же, как сохраняется прямолинейное равномерное движение: бесплатно и неизбежно.
Это такой принцип в интерфейсе — называется «дай нажать».
Приведу три примера.
В сегодняшнем совете был пример, когда у пользователя есть несколько независимых чекбоксов, из которых хотя бы один обязательно должен быть включён:
То есть нужно, чтобы человек выбрал уведомление хотя бы одним каким-то способом, но может накликать и несколько.
Среди вариантов реализации, предложенных автором вопроса, есть такой: чтобы не допустить «пустого» набора, когда остаётся только один включенный чекбокс, его уже не дают выключить:
Это плохое решение: я могу захотеть сначала отключить неподходящий вариант, а потом включить подходящий. Блокировка заставляет меня совершать действия в определённом порядке. Причём это ещё и неочевидно: если у меня останется последней определённая опция, скажем, «в чате», и она заблокируется, то это будет выглядеть так, будто уведомление в чате подключать обязательно, а это неправда. Я хочу его выключить, но интерфейс не даёт мне нажать туда, куда я хочу.
Лучше так: при отключении последнего чекбокса, сразу включать какой-то дефолтный, скажем, «письмом». А если я его отключил последним, то включать второй по предпочтительности, скажем, «по телефону». Так интерфейс не будет мне мешать нажимать куда я хочу, но и не даст оставить недопустимое состояние.
В настройке комментариев в Эгее есть чекбокс «присылать по почте», которому подчинено поле адреса:
Если чекбокс не включён, заполнять поле нет смысла: адрес ни для чего другого не нужен. Если чекбокс включён, а адрес не заполнен, то движок не сможет ничего присылать, потому что не знает адрес. Короче, эти элементы взаимосвязаны.
Можно было бы блокировать поле пока чекбокс выключен — всё равно заполнять его нет смысла. Но это бесит. Может, я хочу заполнить адрес, а потом включить чекбокс? Ещё хуже было бы не давать выключить чекбокс, если адрес заполнен. Я же хочу выключить, дай нажать!
Лучше так: давать заполнить поле, даже если чекбокс выключен; включать чекбокс автоматически, как только в поле что-то вписали. В обратную сторону — аккуратнее: если чекбокс сняли, стирать адрес из поля не надо, мало ли. Пользовательские данные обладают бесконечной ценностью.
Вот возможный вариант реализации выбора даты рождения в интерфейсе:
Как вы знаете, некоторых дней не существует в природе, например не бывает 31 июня. А 29 февраля в некоторые годы бывает, а в некоторые — нет.
Чтобы не дать пользователю ввести несуществующую дату, некоторые разработчики убирают из поля дня несуществующие дни. То есть если выбран месяц июнь, то дня «31» просто не будет в выпадайке. Но что, если у меня день рождения 31 августа? Я хочу ткнуть в 31, а потом выбрать август. Дай нажать!
Бывает обратная проблема: разработчики дают выбрать несуществующую дату, но выводят сообщение об ошибке, когда она выбрана. Это тоже отстой: хорошая форма не засыпает пользователя сообщениями об ошибках, а деликатно помогает их не допустить.
Лучше так: при вводе дня, несовместимого с текущим выбранным месяцем, развыбирать месяц —
Если я выбрал 29 февраля, а выбранном году такого нет, развыбирать год.
Отчасти похожая мысль — кнопка «Купить» всегда доступна.
Большинство маковских программ используют один и тот же фреймворк для обновления, поэтому у них один и тот же тупой сценарий.
Через несколько секунд после запуска программа сообщает, что есть обновление и предлагает скачать:
Ты соглашаешься, она начинает качать:
Пока она качает, ты переключаешься в основное окно программы заниматься тем, зачем её запустил:
Через полминуты программа говорит, что готова обновиться и предлагает перезапуститься, но ты в это время пишешь или читаешь сообщение, поэтому переключаешься обратно в свой диалог и забываешь про обновление. После завершения работы с программой ты её закрываешь.
А потом, когда ты её запускаешь в следующий раз, ты снова видишь вот это:
И снова соглашаешься, и оно снова начинает качать то, что уже давно скачала:
И так до бесконечности.
А должно быть так: если я один раз согласился, то в следующий раз должна запуститься уже новая версия программы.
Коля Товеровский с командой единомышленников выпустил программу для Мака «Конспект». Это специальный блокнот для осмысленного ведения записей во время встреч с клиентом:
Я тоже поучаствовал в этом проекте, правда, в довольно странной роли. Коля хотел сделать такой инструмент, который помогал бы на практике следовать алгоритму сортировки замечаний, описанному в его книге (бесплатная глава по ссылке). И первую версию такого инструмента, ещё в виде веб-приложения «Замечания», начали делать прошлые дипломники — я был арт-директором их команды.
К сожалению, ребята не успели всё доделать и во время защиты показывали продукт так же, как Стив Джобс показывал Айфон: был заготовлен один-единственный сценарий, при котором ничего не глючило. Можете потыкать в ту версию с защиты, но полагаться на неё не стоит. Не знаю, сколько она ещё проживёт по этому адресу.
А в качестве результата «для всех» была представлена только промостраница будущего продукта:
(Ну, что делать, такой флекс. Лучше так, чем не допуститься до защиты).
Несмотря на то, что так вышло, я не считаю время работы над дипломом потерянным. Мы с ребятам заложили ключевой принцип этого инструмента.
В основе была мысль, что штука должна подходить и совсем новичку, который только прочитал книгу, ничего ещё не запомнил, пошёл на первую встречу после этого и волнуется; и опытному переговорщику, скажем, Илье Синельникову.
Когда только начали делать, сначала все представляли какую-то страничку с четырьмя колонками, как нарисовано в книге:
Типа, пишешь где-то текст, а потом отдельные его куски как-то переносишь в одну из колонок.
Я протащил то, что всё это должно работать как простой текст, который можно писать как угодно, и тот факт, что что-то из этих записей это «делаем», что-то — «не делаем», а что-то «откладываем», — не должен этому мешать. Три колонки долго оставались в интерфейсе, но в них ничего не переносилось, а только отмечалось, причём с сохранением связи с исходными записями в конспекте встречи. В основном конспекте может быть и просто какой-то кусок текста, который ни к одной из этих трёх категорий не относится — мало ли, клиент решил рассказать что-то отвлечённое, а я хочу это себе тоже записать. Я должен иметь возможность просто стрелками на клавиатуре дойти до любого места в своих записях и вообще прочитать всё, о чём говорилось на встрече, по порядку.
А потом мы поняли, что три колонки вообще нафиг не нужны, достаточно просто разметки внутри конспекта и автоматически собираемого туду-листа для отправки клиенту после встречи. Все помогалки, объяснялки и сортировалки должны работать как просто декораторы вокруг конспекта, но не мешать мне тупо писать под диктовку клиента что угодно.
Тут руководитель проекта Анна Доронина дала интервью «Кто студенту», где рассказывает о непростой истории проекта. У неё там процесс дизайна в трёх скриншотах, но на самом деле вариантов было намного больше.
С Бирманом легко: он достаточно толерантен, матом не пишет.
Помимо работы над интерфейсом, тогда же на дипломе мы зафигачили иконку (справа):
Мне хотелось, чтобы она дружила с иконкой другого Колиного инструмента, Осьминожки (слева). Поэтому ей нужно было ограничиться одним цветом. Ну а поскольку всё-таки очень хотелось карандаш, пришлось его сделать белым.
В интервью Анны — стенограмма части нашей переписки в процессе работы над иконкой. Правда не вошло, как я замочил предыдущие варианты. Зато вошло немножко про флекс проекта.
После защиты дипломов я перестал следить за судьбой проекта, и выход маковского приложения для меня для самого стал сюрпризом. Зацените тоже: «Конспект».
Сначала написал это в своём телеканале, потом решил перенести сюда.
Когда на своём интерфейсном курсе я начинаю тему привычек, я показываю вот этот скриншот. Это то, что я увидел на своём телефоне, когда попытался подключиться к общественному вайфаю в парке в Будапеште:
Я спрашиваю, что надо сделать, чтобы подключиться. Прошу не подсказывать тех, кто говорит по-венгерски. Все говорят: «нужно поставить галочку и нажать на кнопку!».
Разумеется, сам я на венгерском знаю только «привет», «спасибо» и «осторожно, двери закрываются, следующая станция такая-то», но с лёгкостью тогда преодолел этот интерфейс и подключился к вайфаю:
Это иллюстрирует важность привычек. Мы обычно даже не читаем, что написано, если интерфейс выглядит привычно, а просто действуем по аналогии с тем, как действовали бы в другом интерфейсе.
С недавних пор уже при разборе интерфейса я стал предлагать участникам курса представить, что их интерфейс на венгерском. Ну, если я вижу проблему с привычностью. Это оказалось очень эффективно. Всем сразу становится понятно, что не так.
Вот, например, экран покупки билетов на метро одной из участниц. Здесь можно выбрать один или несколько билетов и тут же начать вносить купюры. Как только денег хватит, автомат выдаст билет и сдачу:
Я говорю, мол, вместо того, чтобы вносить деньги, люди будут жать на кнопку «Подвешено 5 поездок», потому что она стоит там, где обычно стоит кнопка «Далее». Кто-то в классе соглашается, кто-то сомневается.
Но если добавить фразу «представьте, что этот интерфейс на венгерском», все сомнения отпадают — да, подвешенным поездкам там точно не место; там должна появиться большая стрелка, указывающая на купюроприёмник.
Одни из самых страшных интерфейсов встречаются во всяких самодельных узкоспециализированных приложениях. Стоит где-нибудь на производстве компьютер, в котором работник управляет конвейером. Или заходишь в налоговую, и там девушке нужно найти тебя в базе. Или вот пультовая охрана — там тоже был кошмар, пока я не пришёл.
Мало кто в подобных предприятиях понимает, зачем нужен хороший интерфейс, даже если у руководителя Айфон. Последнее может даже быть минусом: люди начинают воспринимать интерфейс как какую-то чисто маркетинговую фичу: красивые иконки, шрифты, анимация. Айфону-то это всё нужно, чтобы он продавался, а нам это зачем? Сотрудники и так будут пользоваться, чем положено, а не чем нравится. Какой смысл тратить деньги на интерфейс?
Но интерфейс в первую очередь не про иконки, а про то, как устроен человек и как он взаимодействует с машиной: как запоминает, как привыкает, как целится, как читает. Хороший интерфейс на работе — не вопрос удовольствия сотрудников (хотя вообще это тоже должно волновать нормального руководителя), а вопрос производительности и минимизации ошибок.
Вот представьте, что при улучшении интерфейса, в который тыкает сотрудник на паспортном контроле, очереди уменьшатся вдвое. Разве это не классно?
Есть такой дизайнерский спор: надо ли превращать курсор мыши в пальчик над кнопками на сайтах. Недавно у меня в очередной раз спросили, как правильно, а у меня нет мнения на этот счёт. Я даже не помню, как у меня сделано в Эгее. В общем, я стал думать, что надо бы разобраться в вопросе. Вот что успел надумать. Это одна из тех заметок, где в конце не будет правильного ответа или инструктажа «делай так».
Сам вопрос возникает вот из-за чего. Кажется непоследовательным, что пальчик есть у одних нажимаемых элементов, ссылок, но не у других, кнопок. И поэтому хочется сделать пальчик у кнопок. Но операционные системы не показывают пальчик над своими кнопками. И если сделать так на сайте, то снова получается непоследовательно: над кнопками на сайтах пальчик есть, а в программах — нет. И поэтому хочется не делать. Как ни крути, получается непоследовательно, людям от этого некомфортно.
Превращение курсора в пальчик — пример обратной связи в интерфейсе. Она подсказывает, что элемент под курсором действительно нажмётся, как ты и предположил.
В классических интерфейсах курсора-пальчика не было. Элементы управления были стандартизованы и сомнений в том, как они сработают, не оставалось:
Меню в каждой программе в одном месте и ведёт себя одинаково — можно дополнительно не подсказывать. Точно так же написанное слово File в другом месте уже никто не воспримет как что-то, что можно нажать. Кнопки передают нажимаемость выпуклостью — их можно поставить где угодно, и человек поймёт. Никакой обратной связи при наведении не требовалось.
Вдавленное белое поле наверняка белое из-за цвета бумаги («можно писать»). Возможно, это уже не работало так железобетонно: курсор приходилось всё же превращать в вертикальную «балку». Но балка ещё лучше стрелки помогает понять границы выделения — не исключено, что её добавили только для этого, а не ради обратной связи. Так или иначе, сегодня она настолько привычна, что без неё мы можем просто не догадаться, что текст вообще можно выделять.
Пальчик появился, насколько я понимаю, с изобретением ссылок. Нужно было как-то показать, что обычный текст — не меню и не кнопка — нажимается. Подчёркивания не хватало для передачи этого ощущения, вот и придумали менять ещё и курсор. И снова, без этого мы не представляем ссылки. Если мы где-то увидим синий подчёркнутый текст, мы, конечно, будем ожидать, что он нажмётся. Но если при наведении курсор останется стрелкой, мы можем сразу решить, что ссылка не работает, даже не попробовав нажать.
Наверняка вопрос о том, не нужно ли делать курсор пальчиком над всем, что нажимается, приходил в голову дизайнерам сразу, когда они его изобрели. Но если бы курсор мыши менялся на пальчик над кнопками, двигать курсор над тулбарами было бы довольно неприятно: он бы постоянно дёргался туда-сюда. Никакой пользы от такой обратной связи нет, это просто раздражающее мельтешение. Когда-то Опера (был такой браузер) всем кнопкам добавила лёгкую подсветку при наведении — это было отвратительно, просто весь тулбар «дрожал».
В одной из версий Виндоуса в тулбарах убрали выпуклость кнопок, оставили просто иконки:
Без лишний рамок тулбар выглядел чище и современнее. Но простых иконок было недостаточно, чтобы передать нажимаемость. Поэтому выпуклая рамка появлялась вокруг кнопки при наведении. В отличие от эффекта с подсветкой в Опере, тут это почему-то не раздражало. Курсор при этом оставался стрелкой.
Получается, у нас есть три варианта. Обратная связь при наведении:
Интересно, что сами ссылки очень долгое время ограничивались только изменением курсора, но сейчас почти все дизайнеры добавляют и изменение вида самой ссылки (обычно это изменение цвета; иногда что-то делают с подчёркиванием). И для меня совершенно точно ссылка, которая не подсвечивается при наведении, выглядит немножко сломанной.
Получается, что большое значение для нашего удобства и формирования ожиданий имеет привычка, а не «последовательность» в выборе обратной связи. От кнопки никто не ожидает пальчика, поэтому никто и не затупит, когда пальчика не будет — любой нажмёт с той же уверенностью. От ссылки все ожидают пальчика и очень многие — подсветки. Поэтому отсутствие этих признаков испортит ссылку.
По мере того, как интерфейсы перестают быть чисто техническим аспектом взаимодействия с машиной и становятся частью образа продукта, на их внешний вид начинают влиять не только соображения понятности и «знакомости» — их ещё хочется забрендировать и сделать уникальными. Чем дальше мы отклоняемся от проверенных десятилетиями образов, тем внимательнее нам приходится быть к тому, чтобы сохранить понятность и сформировать ожидания пользователя.
Подчёркивание текста, тени, блики, градиенты, скруглённые углы, подсветка, курсор-пальчик — это просто некоторые наши инструменты, которыми мы можем пользоваться для достижения нужного эффекта. И ни про один из них нельзя сказать «у любого нажимаемого элемента это должно быть».
В Эгее, кстати, оказалось так: у кнопок курсор — пальчик, но у чекбоксов и радиокнопок — стрелка. Получается как будто совсем уж непоследовательно: не подходит ни логика «всё, что нажимается — с пальчиком», ни логика «как в операционной системе». Но я не хочу ничего менять, как щас — лучше всего.
Ну и в связи со всем этим нужно ещё помнить, что никакого наведения нет на тач-экранах, поэтому надо рисовать элементы понятно изначально.
В квартире, в которой я жил зимой в Тель-Авиве, был такой таймер водогрейки:
Я не сразу понял, как он работает. Попробуйте додуматься.
Переключалочка, где выбрано «Таймер», означает, что это водогрейка работает по таймеру. Можно выключить или включить вручную, но нас интересует именно режим таймера.
Часовая стрелка нарисована на внутреннем кружке, минутная — физически торчит над ним. Они указывают текущее время. Стрелки медленно крутятся, и там даже слышно некое тикание, то есть часы всегда показывают реальное время. А ещё за минутную стрелку можно крутить руками, чтобы настроить часы (кружок с часовой при этом будет сам крутиться в двенадцать раз медленнее). Треугольничек, который показывает примерно на 23-24 тоже указывает текущее время, хотя и чуток не попадает. Сам треугольничек неподвижен, но вокруг него крутится внешнее кольцо с отметками от 1 до 24 часов. Поэтому он всегда смотрит на нужное место в этом кольце.
Красные фигулины соответствуют пятнадцатиминуткам. Если фигулина включена (то есть сдвинута внутрь), то в её пятнадцатиминутку водогрейка греет воду. На фото таймер настроен греть воду с 4 до 5, с 7 до 8, с 14 до 15 и с 18 до 19. При этом включение и выключение водогрейки в нужное время происходит как-то механически. Всё же крутится, и вот, когда треугольничек оказывается на территории включенных красных фигулин, водогрейка включается. Об этом свидетельствует зажигающийся красный светодиод в ЛНУ.
Один из признаков человечного интерфейса — отсутствие технозависимости (читайте совет). А тут явная технозависимость. То есть вся эта штука устроена так, как устроена, только для того, чтобы использовать часовой механизм и всё дальше работало само собой.
Когда я это понял, мне в голову пришли две не очень-то связанные мысли.
Во-первых, эта штука показывает, что технозависимость — не то, чтобы совсем окончательное зло. Это скорее этап, через который проходит интерфейс. Скажем, переключение передач в автомобиле не нужно ни для чего с точки зрения смысла существования автомобиля, но долгое время никто не знал другого способа обойти то ограничение, что у ДВС максимальный крутящий момент достигается только на определённых оборотах. Со временем придумали костыль в виде автоматической коробки передач, но только с появлением электродвигателей в машинах удалось избавиться от передач в принципе (там крутящий момент на любых оборотах нормальный). Если бы люди не разрешили себе технозависимое решение, автомобили бы появились на сто лет позже.
Во-вторых, я стал думать, как бы выглядел нетехнозависимый интерфейс для настройки этого таймера. Вот, допустим, у нас тач-скрин вместо этой шайбы, и что тогда? Оказалось, что задача не такая уж простая. Все штуки, которые приходят в голову, требуют кучи элементов управления, навигации между экранами. При этом ни на одном из этих экранов не будет настолько же наглядной картины расписания, как есть на фото выше (когда ты уже понял, как работает эта штука). Если же всё-таки попытаться разместить всё на одном экране, то все элементы будут слишком мелкими, и всё равно вряд ли удастся добиться такой же пятнадцатиминутной гибкости. Так что, возможно, этот интерфейс не такой уж плохой — примерно как классическая ручка громкости, которая в сто раз удобнее кнопок − и + и сенсорных панелей.
Конечно, вся эта хрень вообще не нужна: из крана просто всегда должна идти вода выбранной температуры без дополнительного программирования водогрейки — именно так работали все краны, встречавшиеся в моей жизни до зимовки в Тель-Авиве.
Вспомнил одну штуку.
Во вчерашнем совете показал интерфейс с рядом чекбоксов:
Хорошо бы упростить человеку выделение ряда чекбоксов. Если я нажал клавишу мыши над чекбоксом и повёл мышь вертикально, не отпуская клавишу, то все чекбоксы, над которыми я «проехал», должны переключиться в то же состояние.
Уточнение про то же состояние — важное. Если первым нажатием я чекбокс включил, то все, по которым я потом веду, должны включиться, а не переключиться (как было бы, если бы я их прокликал по очереди). Если у вас есть под рукой Фотошоп, посмотрите, как там работают «глазики» в панели слоёв — вот так и надо.
Тут есть нюанс. Стандартный чекбокс включается при отпускании, а не при нажатии кнопки. Если нажать кнопку над чекбоксом, а потом отвести мышь и отпустить в другом месте, стандартный чекбокс не переключится. Чтобы реализовать описанную выше штуку, придётся поменять это стандартное поведение и включать чекбокс сразу при нажатии. Обычно это не страшно. Но если изменение состояния чекбокса влияет на что-то ещё, то, возможно, «применение» этого изменения стоит отложить до отпускания клавиши мыши.