{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "Кирилл Беляев: заметки с тегом интерфейс", "_rss_description": "о подаче информации, айдентике, интерфейсах и жизненной среде", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=tags\/interface\/", "feed_url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=tags%2Finterface%2Fjson%2F", "icon": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/user\/userpic@2x.jpg?1662385101", "author": { "name": "Кирилл Беляев", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/", "avatar": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/user\/userpic@2x.jpg?1662385101" }, "items": [ { "id": "734", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/cant-unsee-space\/", "title": "Игра для интерфейсных дизайнеров", "content_html": "

Сantunsee.space<\/a> — в целом отлична игра для интерфейсных дизайнеров. Но есть спорные места. Ниже два примера.<\/p>\n

\n $\"\"$ \n<\/div>\n

Тут вопрос не в том, как красивее обрезана картинка, как по какому изображению проще выбрать товар: по полному, но мелкому или крупному, но обрезанному. И тут нет одного верного ответа, потому что если продаются микроны, то обрезать картинку, наверное, не страшно. А если какое-нибудь специфичное оборудование, то лучше показать целиком. Можно сказать, что если нужно обязательно показывать фотографии целиком, то фиксировать высоту карточки не стоит. И в общем случае это так. Но ситуации бывают разные. Что если 90% каталога какое-нибудь специфичное оборудование снята под нужный формат? а остальные разномастные. Разве можно в этом случае считать фиксированные карточки плохими или кропить фотографии?<\/p>\n

\n $\"\"$ \n<\/div>\n

А тут правильным считаю вариант с разделителем, который на самом деле — объединитель. Возможно, со средней точкой выглядит и лучше, но авторы явно не понимают сути. Илья Бирман 2014-го в помощь.<\/a><\/p>\n", "date_published": "2019-04-03T08:37:32+03:00", "date_modified": "2019-04-03T08:37:28+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/cant-unsee-photo-aspect-ratio@2x.png", "_date_published_rfc2822": "Wed, 03 Apr 2019 08:37:32 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "734", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/cant-unsee-photo-aspect-ratio@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/cant-unsee-text-separators@2x.png" ] } }, { "id": "729", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/items-deleting-from-trash\/", "title": "Удаление позиций из корзины", "content_html": "

Вот условная корзина на сайте с доставкой суши.<\/p>\n

\n $\"\"$ \n<\/div>\n

Часто в таком интерфейсе, когда позиция остаётся в количестве одной штуки, клик в минус её сразу удаляет из корзины. Логично, но неудобно, потому что быстро позицию не вернуть. Чтобы смягчить этот дискомфорт, добавляют модальный диалог.<\/p>\n

Нашёл решение чуть элегантнее. После клика в минус, позиция остаётся в корзине, но не входит в заказ. У позиции с нулевым количеством минус меняется на ведро — удаление становится очевиднее.<\/p>\n

\n $\"\"$ \n<\/div>\n

Клик в ведро окончательно удаляет позицию из корзины без модального диалога.<\/p>\n

Если покупатель не сомневается, то может удалять позиции полностью несколькими кликами в одну и ту же кнопку, что вполне удобно.<\/p>\n", "date_published": "2019-03-27T09:34:19+03:00", "date_modified": "2019-03-27T10:46:15+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/sushi-cart-minus-plus@2x.png", "_date_published_rfc2822": "Wed, 27 Mar 2019 09:34:19 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "729", "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/sushi-cart-minus-plus@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/sushi-cart-trash-icon@2x.png" ] } }, { "id": "719", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/extreme-case-in-apple-watch-timer\/", "title": "Крайний случай в таймере Эпл-вотч", "content_html": "

Крайние случаи — источник неприятностей для интерфейсных дизайнеров. Все иногда забывают посмотреть на них своими глазами.<\/p>\n

Вот таймер в Эпл-вотч. Серые кнопки «00:01:15» и «00:00:30» непохожи на кнопки. Ну, непохожи, проблема-то в чём? Понятно же, что их можно выбрать.<\/p>\n

\n $\"\"$ \n<\/div>\n

Проблема в крайнем случае — когда кнопка одна. Теперь её «нельзя» выбрать, но можно настроить кнопкой ниже.<\/p>\n

\n $\"\"$ \n<\/div>\n

В оригинальном английском всё очевидно, потому что на кнопке прилагательное, которое явно не относится к тому, что выше.<\/p>\n

\n $\"\"$ \n<\/div>\n

В этом случае предложил бы сохранять часть речи и вместо «Настроить» написать «Другой» (таймер) или «Другое» (время). А заодно и поля кнопки стали бы аккуратнее.<\/p>\n", "date_published": "2019-03-19T11:04:04+03:00", "date_modified": "2019-03-19T11:04:01+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/timer-2-buttons@2x.png", "_date_published_rfc2822": "Tue, 19 Mar 2019 11:04:04 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "719", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/timer-2-buttons@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/timer-1-button@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/timer-2-buttons-en@2x.png" ] } }, { "id": "702", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/tags-in-notes\/", "title": "Теги в поле комментария", "content_html": "

Как-то рассказывал, что поле для комментариев легко расширяет функциональность<\/a>:<\/p>\n

\n
Одно поле комментария расширяет функциональность системы, как несколько полей сразу. Люди могут писать в комментарии что угодно, любые данные, для которых нет полей.<\/p>\n<\/blockquote>\n
Поле комментария будет ещё функциональнее, если хранить в нём пометки, которые важны для бизнеса. В таком контексте теги чем-то похожи на стикеры в мессенджерах — если есть такая сущность, тегов можно добавлять сколько угодно, описывая кучу дополнительных свойств. Дешёвый способ повысить узнаваемость и компактность тегов — эмодзи.<\/p>\n
\n $\"\"$ \n<\/div>\n
И ещё один плюс. Развернуть теги в отдельные поля проще, чем слова и фразы из сплошного текста.<\/p>\n", "date_published": "2018-11-27T12:51:50+03:00", "date_modified": "2018-11-27T12:51:47+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/tags@2x.png", "_date_published_rfc2822": "Tue, 27 Nov 2018 12:51:50 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "702", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/tags@2x.png" ] } }, { "id": "699", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/coffee-taste-chart\/", "title": "График кофейного вкуса", "content_html": "
Вкус кофе описывают по-всякому. Даже так:<\/p>\n
\n \n $\"\"$ \n<\/a><\/div>\n
В Ггет<\/a> представили кислоту и силу обжарки в виде осей абсцисс и ординат. И расположили свой ассортимент на таком графике. Получился дополнительный инструмент выбора. Из-за представления всех продуктов в одной системе координат, их гораздо легче сравнивать. Предполагаю, что мне бы понравился такой вариант:<\/p>\n
\n $\"\"$ \n<\/div>\n
В классификации оттенков вкуса я не разбираюсь, поэтому сужу только о видимой информации. Похоже, на графике перемудрили с цветами. Там две оси, которые хорошо бы показали два градиента. Горизонтальный — от зелёного (кислого) до оранжевого (землистого) и вертикальный — от светлого (слабая обжарка) к тёмному (сильная):<\/p>\n
\n $\"\"$ \n<\/div>\n
P. S. Спасибо Лео за ссылку!<\/p>\n", "date_published": "2018-11-23T11:37:43+03:00", "date_modified": "2018-11-23T13:15:48+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/scaa-flavor-wheel@2x.jpg", "_date_published_rfc2822": "Fri, 23 Nov 2018 11:37:43 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "699", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/scaa-flavor-wheel@2x.jpg", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/gget-chart@2x.jpg", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/gget-chart-recolor@2x.jpg" ] } }, { "id": "673", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/email-domain-suggestions\/", "title": "Подсказка основных почтовых доменов", "content_html": "
Когда даю сайту почту в первый раз, автозаполнения ещё нет, а вводить адрес целиком лень. Очевидная польза — подсказать основные почтовые домены. Предполагаю, что 4-5 часть пользователей вводит домен одной из основных почтовых служб.<\/p>\n
Пока реализацию встретил только у Али-экспресса. Отдельно отмечу, что классно знать о локально популярных доменах, как это делает Али:<\/p>\n
\n
\n $\"\"$ \n $\"\"$ \n $\"\"$ \n<\/div>\n<\/div>\n", "date_published": "2018-09-19T16:25:26+03:00", "date_modified": "2018-09-24T10:31:37+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/email-domain-1@2x.png", "_date_published_rfc2822": "Wed, 19 Sep 2018 16:25:26 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "673", "_e2_data": { "is_favourite": true, "links_required": [ "system\/library\/jquery\/jquery.js", "system\/library\/fotorama\/fotorama.css", "system\/library\/fotorama\/fotorama.js" ], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/email-domain-1@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/email-domain-2@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/email-domain-3@2x.png" ] } }, { "id": "667", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/menu-bar-modality\/", "title": "Модальность меню-бара в Мак ОС", "content_html": "
У элементов бывает сложное поведение, ошибки которого проявляются редко. Но это не значит, что о них не стоит думать. Даже если чинить дороже, знать об ошибках полезно, чтобы внятно отвечать на вопросы как минимум. Поэтому рассказываю о забавном сочетании правил в Мак ОС. Поскольку это не просто сервис, а целое ОС, уверен, что негодующих по этому поводу пользователей достаточно.<\/p>\n
Меню приложения в Мак ОС прибито к верхнему краю экрана, независимо от положения и состояния приложения. Это удобно, потому что легче попасть — вместо прицельного клика легко упереть курсор в верхнюю границу и двигать вправо-влево. В этом же меню<\/a> живут иконки статусов особых приложений, поиск, центр уведомлений и меню самой ОС (яблоко в начале строки).<\/p>\n
\n $\"\"$ \n<\/div>\n
Когда приложение зависает, меню приложения и яблоко перестают отвечать. Иконки-статусы, поиск и прочее справа работают. Если перейти в работающее приложение, яблоко — снова кликабельно, хотя это ровно один и тот же элемент с одинаковым набором функций внутри.<\/p>\n
Чтобы закрыть приложение, запускают диалоговое окно «Завершить принудительно» в меню-яблоке, выбирают в нём зависшее приложение и жмут кнопку «Завершить принудительно».<\/p>\n
\n $\"\"$ \n<\/div>\n
На картинке выше невозможная ситуация. Если приложение зависло, то открыть «его» яблоко не получится, придётся идти в работающее. Вместо того, чтобы дать разобраться с неработающим приложением, которое сейчас в локусе внимания, ОС отправляет в другое приложение, чтобы запустить принудительное завершение. При этом элементы справа той же строки работаю как ни в чём не бывало. Эта модальность дезориентирует. Чтобы отследить, что происходит и где граница неработающего в первый раз нужно осознать, что происходит что-то мутное и сфокусироваться на работоспособности яблока. Происходит это на фоне зависшего приложения и желания его скорее перезапустить.<\/p>\n
Чтобы не сталкиваться с этой модальностью, жму на клавиши.<\/p>\n
\n
⌥⌘Esc вызывает диалог «Завершить принудительно».<\/li>\n
Удерживание ⌥⌘⇧Esc закрывает активное приложение в любом состоянии.<\/li>\n<\/ol>\n", "date_published": "2018-08-22T15:45:39+03:00", "date_modified": "2018-09-05T11:45:24+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/menu-bar@2x.jpg", "_date_published_rfc2822": "Wed, 22 Aug 2018 15:45:39 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "667", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/menu-bar@2x.jpg", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/force-quit@2x.png" ] } }, { "id": "649", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/buttons-and-text-style\/", "title": "Стиль кнопок и текста", "content_html": "
Синхронизирую кнопки с текстовыми стилями. Обычно стилей 4-5, кнопок хватает трёх: размером с основной текст и с подзаголовоки 2-го и 3-го уровней. Или 2-го и 4-го — зависит от задачи. Для массового и броского — 1-го.<\/p>\n
Такая синхронизация немного гасит шум и сильно упрощает сбор строк из текста и кнопок. А наличие принципа разгружает голову. При умелой вёрстке упрощает ЦСС и корректировки.<\/p>\n
Синхронизирую кегль, интерлиньяж и разрядку, если кнопки не капительные. Начертание чаще сохраняю для жирных и полужирных и «поджирняю» для нормальных и прямых текстовых стилей.<\/p>\n", "date_published": "2018-05-28T10:57:06+03:00", "date_modified": "2018-05-28T11:40:50+03:00", "_date_published_rfc2822": "Mon, 28 May 2018 10:57:06 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "649", "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [] } }, { "id": "637", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/locus-of-attention-in-youtubes-warning\/", "title": "Локус внимания в предупреждении Ютьюба", "content_html": "
Когда в Сафари не работал панорамный просмотр видео, Ютьюб показывал предупреждение. И добросовестно выделял его цветом ярче окружения:<\/p>\n
\n $\"\"$ \n<\/div>\n
Я не сразу его заметил, поэтому появился этот скриншот. Внимание зрителя захватывает само видео, и всё вокруг становится неинтересным. В этом конкретном случае<\/a> смысл в «изучении» пространства — это интерактивная версия выставки. Без панорамного просмотра смысла почти нет. В такой ситуации пропустить сообщение вдвойне неприятно.<\/p>\n
Чтобы человек с большей вероятностью заметил подобное сообщение, его лучше поместить ближе к объекту внимания. Например, написать сообщение поверх видео:<\/p>\n
\n $\"\"$ \n<\/div>\n
Чтобы сделать сообщение ещё заметнее, увеличил кегль. Ещё увеличил область клика: была кнопка «Подробнее» — стала ссылка размером с весь текст:<\/p>\n
\n $\"\"$ \n<\/div>\n", "date_published": "2018-05-18T11:31:10+03:00", "date_modified": "2018-05-18T10:45:53+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/youtube-panoramic-video-warning@2x.jpg", "_date_published_rfc2822": "Fri, 18 May 2018 11:31:10 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "637", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/youtube-panoramic-video-warning@2x.jpg", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/youtube-panoramic-video-warning-relayout@2x.jpg", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/youtube-panoramic-video-warning-redesign@2x.jpg" ] } }, { "id": "636", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/opening-hours-suggest\/", "title": "Предположение о часах работы", "content_html": "
На странице заведения Форсквер<\/a> показывает часы его работы. Если время не указано точно, сервис предполагает, опираясь на чекины. Я за такие штуки, потому что они добавляют пользы.<\/p>\n
\n $\"\"$ \n<\/div>\n
Проектируя похожие блоки, важно показывать, что это именно предположение и на основе всего оно сделано. С этим у Форсквера хорошо, но остальное в блоке подано слабо:<\/p>\n
\n
Он контекстно меняет порядок дней недели, что мешает сформировать привычку.<\/li>\n
Не пушит, какой сегодня день недели, хотя это может помочь принять вспомнить, что сегодня сюда не нужно или ещё что-то в таком духе.<\/li>\n
Каждому часу добавляет мусорные «:00», хотя все данные округлены до полных часов.<\/li>\n
Отдельные приветы «Полудню» и диапазону «Сб — Вс».<\/li>\n<\/ol>\n
Делал бы так. Если данные точные, заголовок будет просто «Открыто до 19:00».<\/p>\n
Судя по чекинам, открыто<\/span>:<\/b><\/p>\n
\n\n\n\n\n\n\n\n
<\/td>\n Пн<\/td>\n 10...16<\/td>\n <\/td>\n <\/td>\n<\/tr>\n
<\/td>\n Вт<\/td>\n 11...15<\/td>\n 17...18<\/td>\n <\/td>\n<\/tr>\n
<\/td>\n Ср<\/td>\n 11...12<\/td>\n 14...18<\/td>\n <\/td>\n<\/tr>\n
<\/td>\n Чт<\/td>\n 11...13<\/td>\n 15...16<\/td>\n 18...19<\/td>\n<\/tr>\n
Сегодня<\/td>\n Пт<\/td>\n 11...19<\/span><\/td>\n <\/td>\n <\/td>\n<\/tr>\n
<\/td>\n Сб, Вс<\/td>\n 10...19<\/td>\n <\/td>\n <\/td>\n<\/tr>\n<\/table>\n<\/div>\n", "date_published": "2018-05-03T12:35:18+03:00", "date_modified": "2018-05-03T12:44:21+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/foursquare-suggest@2x.png", "_date_published_rfc2822": "Thu, 03 May 2018 12:35:18 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "636", "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/foursquare-suggest@2x.png" ] } }, { "id": "622", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/erizing-specific-symbols-from-input-field\/", "title": "Удаление выборочных символов при вводе в поле", "content_html": "
В интерфейсах бывают специфичные поля, которые не принимает какие-то символы. Например, в телефонном номере или пин-коде не будет букв.
\n
\nЕсли из лейбла (подписи к полю) очевидно, какие символы не подойдут, незачем разрешать их ввод. Лучше нагрузили компьютер уборкой лишнего и не просить человека что-то стирать.
\n
\nБеспокоить сообщениями о неправильном вводе при этом не нужно. Какой шанс, что человек хотел ввести в номер букву? Подсказка «В номере телефона допустимы только цифры...» только отвлекает. Все знают, что букв там быть не должно: «Спасибо, кэп!»
\n
\nДля таких полей в техзадании для разработчика пишут «нельзя ничего, кроме цифр, скобок, тире и дефисов». Это двусмысленно. Не реагировать на нажатия клавиш, или вводить, а потом стирать?
\n
\nПредлагаю разрешать вводить всё, а после ввода неподходящего символа, сразу его стирать. Сначала кажется, что будет дёргающаяся ерунда. Но она даст пользователю обратную связь. Покажет, что и поле, и клавиатура работают. Ещё покажет, что человек ввёл что-то не то. Вряд ли он хотел писать буквы в телефонный номер, скорее промахнулся. Заметить стирающуюся букву проще, чем не введённую.<\/p>\n", "date_published": "2018-02-28T11:37:14+03:00", "date_modified": "2018-02-28T11:44:57+03:00", "_date_published_rfc2822": "Wed, 28 Feb 2018 11:37:14 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "622", "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [] } }, { "id": "614", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/sealing-columns-in-table\/", "title": "Уплотнение столбцов в таблице", "content_html": "
Таблицы удобнее читать, когда столбцы стоят плотно и взгляд не перепрыгивает большие дыры, идя по строке. Второй плюс узких столбцов — их больше влезает в ширину экрана. Особенно это актуально в информационно насыщенных таблицах. Часто узкому содержанию мешают широкие заголовки, как в столбцах Е и F :<\/p>\n
\n $\"\"$ \n
Скриншот с сайта университета Мэриленда<\/a><\/div>\n<\/div>\n
Столбцы А...F за 1990-й. Год можно вынести на строку выше и не повторять шесть раз. Этого хватит, чтобы сузить столбцы, но если оставшиеся заголовки будут длиннее подойдёт следующий приём. Показывать буду на таком кусочке:<\/p>\n
\n $\"\"$ \n<\/div>\n
Повторюсь: приём подойдет только для случаев, когда столбцы связаны по смыслу. Сначала собираю заголовки в один через запятую. И сбиваю содержание плотнее:<\/p>\n
\n $\"\"$ \n<\/div>\n
Заголовки связаны со столбцами только порядковым положением. Такой связи бывает недостаточно. Поэтому усиливаю связь цветом. Достаточно одного не крайнего столбца на каждые три-четыре столбца. Красить лучше со смыслом, но можно и механически через один:<\/p>\n
\n $\"\"$ \n<\/div>\n
Теперь нужно придумать, что делать с сортировкой. У исходной таблицы заголовки могли быть кликабельными. Теперь так не получится.<\/p>\n
\n $\"\"$ \n<\/div>\n
Добавляю линейку, отделяющую содержание от заголовка. Режу её на кусочки по ширине каждого столбца делаю повыше и превращаю в кнопки:<\/p>\n
\n $\"\"$ \n<\/div>\n
Тестируйте перед внедрением.<\/p>\n", "date_published": "2018-01-26T13:19:31+03:00", "date_modified": "2018-01-26T20:45:41+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/excel@2x.gif", "_date_published_rfc2822": "Fri, 26 Jan 2018 13:19:31 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "614", "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/excel@2x.gif", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/table-incompact@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/table-combined-columns@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/table-combined-color-columns@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/table-sorting@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/table-combined-columns-sorting@2x.png" ] } }, { "id": "610", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/cryptowatch\/", "title": "Криптовотч", "content_html": "
Смотрите, какой сайт с котировками криптовалют — cryptowat.ch<\/a><\/p>\n
\n $\"\"$ \n<\/div>\n
Терминальный минимализм такой. Я бы побился за меньшее число линеек — много шума от них:<\/p>\n
\n $\"\"$ \n<\/div>\n
В карточке ещё интереснее:<\/p>\n
\n $\"\"$ \n<\/div>\n
В стакане одинаковые цифры гасят прозрачностью. Когда отличие в разряде, подсвечиваются всё отличные цифры, а потом «счётчик» обнуляется и только подсвечиваются отличия от последнего «разрядного отличия» (вторые строки снизу и сверху):<\/p>\n
\n $\"\"$ \n<\/div>\n", "date_published": "2018-01-23T15:48:20+03:00", "date_modified": "2018-01-23T15:58:12+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/cryptowatch@2x.png", "_date_published_rfc2822": "Tue, 23 Jan 2018 15:48:20 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "610", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/cryptowatch@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/cryptowatch-redesign@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/cryptowatch-inside@2x.png", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/cryptowatch-differences@2x.png" ] } }, { "id": "601", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/auto-keys-buttons\/", "title": "Кнопки на автоключах", "content_html": "
Такой ключ у Фольксвагенов, у Шкод и Ауди похожие:<\/p>\n
\n $\"\"$ \n<\/div>\n
Кнопки похожи и стоят в ряду. Внешний вид подразумевает, что работают они одинаково. Верхняя кнопка разблокирует машину, нижняя — заблокирует, а средняя — разблокирует только багажник. Правда, непонятно тогда, как его заблокировать. Только со всем автомобилем? Или повторное нажатие в среднюю кнопку тоже сработает?<\/p>\n
На деле средняя включает программу «Разблокируй багажник и заблокируй после того, как его закроют». Эта программа вписывается в сценарий «Достать багаж, который займёт руки, и не беспокоиться о блокировке багажника, достаточно умудриться его закрыть».<\/p>\n
Через 1,5 года я обратил внимание на среднюю кнопку. И после пары раз запомнил, как работает. Внешним видом это не объяснить, но можно намекнуть, что не так же, как соседние. Вот пульт какой-то модели Тойоты. Очевидно, что «багажник» отличается:<\/p>\n
\n $\"\"$ \n<\/div>\n
Кстати, ещё непонятно, почему такая функция только у багажника. Программа была бы удобна для всех дверей — люди багаж везде возят.<\/p>\n", "date_published": "2018-01-14T20:44:21+03:00", "date_modified": "2018-01-15T08:58:37+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/vw-key@2x.jpg", "_date_published_rfc2822": "Sun, 14 Jan 2018 20:44:21 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "601", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/vw-key@2x.jpg", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/toyota-key@2x.jpg" ] } }, { "id": "599", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/featurism\/", "title": "Фичеризм", "content_html": "
Есть такой термин «фичеризм», от слова «фича» (feature с английского — свойство). Этим термином ругают излишние возможности, функции изначально цифровых, но теперь уже любых продуктов. Непонятные людям функции тоже попадают под фичиризм.<\/p>\n
Бывает супердёшево завернуть элемент в ссылку и добавить новую связь между сущностями. И люди будут быстрее добираться куда нужно. Но дело чуть сложное, по-моему.<\/p>\n
Вместе с возможностью приходит ответственность. Легко пойти по новой ссылке, но получится ли операция в целом быстрее или путь назад займёт больше времени, чем раньше. И вот человек перед выбором. А любой выбор сжигает мышление. Количество решений, которые человек принимает за единицу времени ограничено. Потом придёт усталость и работа на автомате. Если выбор будет сложным, ошибки будут чаще. Это вольный пересказ Максима Дорофеева<\/a>, которого советую читать.<\/p>\n
У меня план примерно такой:<\/p>\n
\n
Не пустить в работу функции, которые дублируют существующие.<\/li>\n
Спроектировать путь, чтобы понимать контекст, в котором функция применяется. Путь — набор действий от начального состояния до полностью решённой задачи. Взяли обычную фотографию — получили состаренную в фотошопе. Выбор монохромного режима и цвета, наложение текстур, затемнение углов... Всё это один путь.<\/li>\n
Убедиться, что пути с использованием новой функции не дублируют существующие пути и не порождают паразитные пути. Тут может понадобиться полноценная дорожная карта с хайвеями и переулками.<\/li>\n
После внедрения функции следить, как люди прокладывают маршруты. И если что-то ломается, проходить список заново.<\/li>\n<\/ol>\n", "date_published": "2018-01-08T19:18:07+03:00", "date_modified": "2018-01-08T19:03:20+03:00", "_date_published_rfc2822": "Mon, 08 Jan 2018 19:18:07 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "599", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "596", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/notes\/", "title": "Комментарии к сущностям в системах", "content_html": "
В системах бывают комментарии. Например в ЦРМ<\/a> у клиента или заказа. Стыдно признаваться, что не жаловал эти поля. Видел их так: чёткого назначения нет, используются раз в сто лет, не укладываются в формат, ломают таблицы.<\/p>\n
Крутой Анатолий Буров<\/a> показал другую сторону. Одно поле комментария расширяет функциональность системы, как несколько полей сразу. Люди могут писать в комментарии что угодно, любые данные, для которых нет полей. С хорошим поиском совсем сказка.<\/p>\n
А в таблице можно делать так:<\/p>\n
\n $\"\"$ \n<\/div>\n
Анатолий Буров добавляет<\/b>
\nКомментарии — это дешёвый способ сделать систему устойчивой к изменениям в окружающем мире.<\/p>\n
Когда мы выкатываем интерфейс, есть вероятность, что в ближайшие пару лет он будет работать в первозданном виде. При этом условия будут меняться: появятся новые сценарии и новая информация, которые сложно предусмотреть заранее (если б могли предусмотреть, предусмотрели бы :—)<\/p>\n
Поля для записей в свободной форме дают людям возможность и дальше использовать старую систему в новых условиях, не страдая от того, что она никак не дорабатывается. Они между собой договорятся, что и как туда записывать — ну, например, хэштегами, — а поиск не даст заблудиться.<\/p>\n
А когда разработчики-таки добавят в систему нужные поля, можно будет скриптом перенести хештеги из комментариев в соответствующие структуры. И всем будет счастье.<\/p>\n", "date_published": "2017-12-21T12:26:34+03:00", "date_modified": "2018-11-27T12:20:26+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/note@2x.png", "_date_published_rfc2822": "Thu, 21 Dec 2017 12:26:34 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "596", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/note@2x.png" ] } }, { "id": "568", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/map-zooming-and-quasi-mode\/", "title": "Масштабирование карты и квазирежимы", "content_html": "
Стоит такая интерфейсная задача — изменение масштаба на картах, которые занимают часть экрана.<\/p>\n
В какой-то момент карты в интернете начали менять масштаб с помощью колеса прокрутки. Для полноэкранных это не так страшно, но для карт на страницах с прокруткой — та ещё проблема. Прокручиваю страницу, и когда курсор попадает на карту, та перехватывает прокрутку и масштабируется. Не получаю ожидаемое перемещение по странице, сбиваю настроенный масштаб карты и теряюсь от неожиданности.<\/p>\n
Тому виной модальность — режимы, которые не осознаются, но меняют интерпретацию действий. В примере с картой режим не переключается явно, а переключён по умолчанию — одни элементы реагирует на прокрутку так, другой — иначе. Даже сталкиваясь с этим раз в день, я не запоминаю, что карта в другом режиме.<\/p>\n
Модальность лечат, задавая разные действия для разных команд. Если так не получается, пробуют квазирежимы — режимы, которые человек явно осознаёт. Зажатый шифт в сочетании с буквами даёт не строчные, а прописные.<\/p>\n
Недавно в Гугл-картах, которые встраиваются в страницы, появилось решение проблемы с прокруткой. Разработчики ввели для таких карт квазирежим — для масштабирования теперь не достаточно прокрутки, нужно ещё зажать ⌘ или Сtrl. Скриншот:<\/p>\n
\n $\"\"$ \n<\/div>\n
Это решение далеко от идеала, но чинит основной сценарий. Менять масштаб на встроенных картах нужно редко, важнее информация вокруг и быстрый способ открывать полноэкранную карту.<\/p>\n
Минус решения в том, что подсказка появляется при прокрутке карты. Привычку менять масштаб прокруткой уже сформировали. А теперь прокрутка не масштабирует карту, а показывает подсказку. Сначала остановлюсь, читаю и спешу тренировать новую привычку.<\/p>\n", "date_published": "2017-11-24T10:45:20+03:00", "date_modified": "2017-11-24T13:31:24+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/google-maps-scroll@2x.png", "_date_published_rfc2822": "Fri, 24 Nov 2017 10:45:20 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "568", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/google-maps-scroll@2x.png" ] } }, { "id": "558", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/mission-control\/", "title": "Мишн контрол", "content_html": "
Мак радует функцией «Мишн контрол». За неё отвечает клавиша «F3»:<\/p>\n
\n $\"\"$ \n<\/div>\n
Нажатие на одну кнопку показывает открытые окна — супер-наглядно:<\/p>\n
\n $\"\"$ \n<\/div>\n
Одно но: в этом режиме не видны свёрнутые окна. Ждать, что человек помнит свёрнутое, мега-оптимистично. Если сверить запущенные приложения в Доке с окнами и рабочими столами, можно заметить, что окон не хватает. Но это требует много времени и внимания — раз. А если у одного приложения открыто больше двух окон и хоть одно из них свёрнуто, найти его через Мишн контрол не получится — два.<\/p>\n
Выделенное окно Файндера было открыто уже во время первого скриншота:<\/p>\n
\n $\"\"$ \n<\/div>\n
В настройках есть галочка «Группируй окошки по приложениям», советую включить, будет проще:<\/p>\n
\n $\"\"$ \n<\/div>\n
Так вот, группировать нужно по умолчанию, убрав галочку из настроек, а иконки приложения с глаз долой. А скрытые окна показывать под активными и приглушить:<\/p>\n
\n $\"\"$ \n<\/div>\n", "date_published": "2017-10-13T14:01:41+03:00", "date_modified": "2017-10-13T14:01:24+03:00", "image": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/f3-macbook@2x.jpg", "_date_published_rfc2822": "Fri, 13 Oct 2017 14:01:41 +0300", "_rss_guid_is_permalink": "true", "_rss_guid": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/mission-control\/", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/f3-macbook@2x.jpg", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/desktop@2x.jpg", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/desktop-2finders@2x.jpg", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/desktop-group@2x.jpg", "https:\/\/www.kirillbelyaev.com\/ru\/blog\/pictures\/desktop-hidden@2x.jpg" ] } }, { "id": "548", "url": "https:\/\/www.kirillbelyaev.com\/ru\/blog\/?go=all\/inscription-as-an-interface\/", "title": "Надпись, как интерфейс", "content_html": "
Надпись тоже бывает интерфейсом. На фото — капельная кофеварка<\/a>, она готовит 1-1,5 литра фильтрового кофе. После приготовления, кофеварка подогревает кофейник, потому что сложно выпить литр кофе за раз. Чтобы аппарат не перегревался при подогреве и не вынуждал человека следить за температурой, в большинстве кофеварок есть автовыключение. Но не на всех есть надписи. Об функции написано в инструкции, но человек мог её не читать, потому что это 20-я кофеварка в его жизни, но у первых 19 не было автовыключения, или забыть, потому что люди что угодно забывают. Надпись тут работает, как обратная связь, постоянно показывает перманентное состояние системы.<\/p>\n
\n $\"\"$ \n<\/div>\n
Добавлено попозже. Меткий твит:<\/p>\n
Строго говоря, надпись — это всегда интерфейс.<\/p>\n
— Вадим Юмадилов (@Yumadilov) 23 сентября 2017 г.<\/a><\/p>\n<\/blockquote>