Заметил, что многие дизайнеры интерфейса не отличают сортировку и фильтрацию. Говорят: «тут можно отсортировать квартиры по конкретному району». Иногда это просто оговорка и на понимание не влияет. Но в моей жизни такие разговоры чаще всего случаются как раз в обсуждении деталей поведения сложных интерфейсов. За неверным выбором слов часто скрывается и недопонимание сути, а как следствие — фиговое проектирование.

Сортировка — это когда у вас есть массив данных, и вы выбираете в каком порядке показывать эти данные: по убыванию цены, по возрастанию рейтинга или по дате изменения.

Фильтрация — это когда у вас есть массив данных, и вы выбираете, какую его часть показать: только у моря и с завтраком, с массой в пределах от 0,5 до 3 масс Солнца или только содержащие подстроку «жопа».

Если у вас 1183 записи, то как их ни сортируй, их останется 1183, а при фильтрации будет показана только их часть.

Значения какого-то поля у многих записей могут совпадать, скажем, у сотни треков в музыкальной коллекции может быть один и тот же исполнитель. Тогда сортировка может быть вложенной, например треки можно отсортировать по названию исполнителя; внутри исполнителя — по дате релиза; внутри релиза — по произвольному порядковому номеру трека в релизе. Дать пользователю управлять такими нюансами в интерфейсе — нетривиальная задача.

Ещё замечу, что когда мы говорим «сортировать по тому-то», мы можем иметь в виду как само поле, которое используется для упорядочивания (по имени), так и принцип этого упорядочивания (по убыванию, по алфавиту). Мы можем брать даже какую-то производную поля и уже её упорядочивать, например, можно отсортировать студентов по убыванию длины имени или города по возрастанию населения.

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

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

Отсортировать по району можно: сначала показать записи из Аннина, потом из Бутова, потом из Внукова. Придётся ещё решить, как сортировать записи уже внутри района, ведь их явно будет много в каждом. Но вот отсортировать «по конкретному району» невозможно: это всё равно что отсортировать всех по конкретному росту 172 см.

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

Столкнулся с дизайн-системой, где у всех компонентов отрисованы состояния «скелет» — это типа как выглядит элемент, пока он не загрузился. Дизайнеры вообще говорили «скелетон», но скелетон — это такой бобслей для одиночек, а skeleton — это скелет. С этим состоянием есть проблема, сейчас объясню.

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

Так что же не так с состоянием компонента «скелет»? То, что скелет — это состояние экрана целиком, а не отдельного компонента. (Если уж на то пошло, у компонента может быть состояние «кость», а не «скелет».)

Во-первых, рисование отдельных скелетных состояний компонентов провоцирует дизайнеров на рисование излишне детализированных скелетов экранов. Вот Вконтакте например:

Зачем столько мусора? Чтобы показать, что экран ещё грузится, достаточно такого:

Да и ещё спокойнее можно.

Во-вторых, во время загрузки экрана он обычно не знает, какие именно компоненты на нём будут, чем они будут наполнены, какого они будут размера. То есть даже непонятно, какие именно компоненты в этом состоянии «скелет» туда ставить, приходится выдумывать. В то же время, если какие-то элементы на экране нужны независимо от подгружаемых данных, скажем, кнопки навигации, то их стоит сразу показывать в нормальном виде, безо всяких скелетов.

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

В ответ на мою критику исследований мне иногда говорят, мол, ну а как же можно браться за задачу, не разобравшись во всех деталях! Вы вон в бюро тоже всё это делаете, просто не называете это «исследованием»!

Конечно не называем, ведь это не исследование.

Вот вам критерий: если для получения ответа достаточно задать вопрос — это не исследование.

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

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

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

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

Проверочный вопрос, чтобы понять, бояться ли конкуренции со стороны нейросетей. Вы в основном делаете, что вам говорят, или что хотите? Если первое, то стоит бояться, а если второе — то не стоит.

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

Если вы цените то, что публикуете; хотите, чтобы оно не пропало и чтобы аудитория не потеряла к нему доступ, дальновиднее писать в блоге у себя, на собственном сайте. Я для этого использую и рекомендую вам Эгею — движок, который я сделал и развиваю всю жизнь. Это программа, которая работает на вашем сайте и предоставляет инструменты для ведения блога, а посетителям показывает публикации и даёт писать комментарии. Нужно пройти некоторый путь, чтобы этим воспользоваться: купить себе домен, подключить хостинг, установить туда саму Эгею. Но это намного проще, чем, например, научиться кататься на велосипеде. Надо один раз разобраться, а потом на всю жизнь.

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

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

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

Попробуйте Эгею!

Никто не говорил, что в Стамбуле довольно примечательные уличные таблички:

Своей кричащей расцветкой они немного похожи на флаги:

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

На средней полосе пишется махалля, а на нижней полосе — район. Кадыкёй:

У каждого района ещё и свой цвет этой полосы. Бейоглу:

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

Вёрстка умеет адаптироваться к длинным названиям и всяким припискам типа «профессор». Шишли:

Таблички умеют крепиться как на дома, так и на столбики:

Обратите внимание на стрелочки справа снизу. Когда табличка на доме, у стрелочки подсказывают номера домов, а когда на столбике — не подсказывают. Но тогда стрелочка становится двойной. Такой дизайн!

Бешикташ:

Кстати, дизайн стрелочки на удивление уродский, но всё равно хороший:

Даже на разной высоте таблички хорошо смотрятся, кто бы мог подумать! Редкие стрелочки в две стороны:

Красиво выцветают на солнце:

Ну иногда не очень красиво:

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

Вот где прекрасное сочетание цвета таблички и цвета дома:

Снова на разной высоте, а ну и что:

Овальная табличка сверху — какая-то несистемная

Синий дом и красная табличка. Ну кайф:

Удивительно, что в огромном Стамбуле все таблички сделаны в одном дизайне:

Мне ни разу даже не попалась «примерно похожая табличка», где кто-то бы взял шрифт наугад или поломал бы отступы. Нет, всё одинаково:

Для Стамбула вполне ожидаем был бы полный разнобой и бардак. Но такого уровня систематизации я не встречал нигде:

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

А эта табличка была в общем рассказе про Стамбул:

Фотографии из поездок в сентябре и октябре 2022 года. Слетайте в Стамбул!

Ещё Стамбул:

• Общее впечатление

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

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

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

Одна из главных особенностей города — мучительная рельефность.

Это мило выглядит, но гулять по такому городу невозможно — слишком много нужно сил.

В сочетании с плохо работающим такси и отсутствием нормальной системы оплаты транспорта это всё делает город очень недоступным.

Но, конечно, красиво, когда видно так далеко:

Трамвайчик:

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

Типа такого:

Ну или можно плавать на паромах туда-сюда с таким видом:

Тротуаров в городе, считай, нет, что дополнительно затрудняет перемещения. Но идея вот так сидеть, пить чай, и мешать перемещению других, кажется привлекательной:

Ещё один красивый вид далеко:

Непонятное:

Тут слева видна уличная табличка — не трудно догадаться, что про них будет отдельный большой пост:

Тут тоже видна, но это какая-то нестандартная, про такие поста не будет:

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

Пока на этом всё.

Фотографии из поездок в сентябре и октябре 2022 года. Слетайте в Стамбул!

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

А какого чёрта это так тупо? Почему нельзя, чтобы я выбирал любой отрезок времени? Если мой самолёт прилетает в 8 утра, я хочу приехать и заселиться сразу. Если улетает в полночь, я хочу поехать в аэропорт из отеля. Поручите компьютеру разруливание всех возможных коллизий.

На железной дороге вообще до всяких компьютеров спокойно умели продавать билеты от Воронежа до Самары на поезд Белгород — Новосибирск и учитывать, когда какая койка освобождается, чтобы оптимально использовать все места.

Неужели в 2026 году нельзя сделать систему бронирования, которая будет динамически считать гибкие предпочтения всех гостей?

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

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

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

Любой провинциальный чиновник выберёт зелёный цвет для окраски предметов в парке. Дизайнер предложит чёрный, но чёрный — это ведь мрачно. Коллеги убедят чиновника, что логичнее брать зелёный: в парке зелёная трава, зелёные деревья, вот и фонарные столбы и мусорки пусть тоже будут зелёными:

Но любой оттенок зелёного выглядит неестественно на фоне реального разнообразия живых зелёностей. Надо слушать дизайнера и брать чёрный:

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

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

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

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

Для этого вводим стандартное обозначения прав сайтов и приложений. Допустим, это будет щит, но это не важно. Вставляем его рядом с названием сайта в адресную строку всех браузеров:

И куда-нибудь сюда во всех приложениях, но можно ещё дать способ показать внутри своего интерфейса тоже:

Даём АПИ, чтобы подписать в окне настройки разрешений каждое разрешение объяснением того, зачем оно нужно. Всё, теперь сайт или приложение могут и в своём интерфейсе сколько угодно говорить, мол, чтобы работали видеозвонки, мне нужно доступ к камере; и в самом интерфейсе настройки под разрешением уведомлений уверять, что спамить не будут. Но не могут сами ничего попросить!