Визуальная конструкция элементов интерфейса

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

Можете ли вы понять по переключателям, включены ли они, или нет? Я воспринимаю этот элемент интерфейса как белый квадрат, перемещающийся внутри черного прямоугольника. Он находится справа, поэтому переключатель включен. Но я-то знаю, что соцсети у меня не подключены.

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

Фирменный оранжевый цвет должен был показать активацию переключателя. Но у меня усилилось ощущение того, что белый квадрат, представляющий ручку переключателя, переместился налево. А оранжевый цвет говорит: «Внимание, выключено!».

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

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

Фирменный стиль не должен быть помехой для разработки и внедрения понятных элементов интерфейса.

Деление на код и данные в ООП

Любая программа, выполняемая на современных процессорах, состоит из данных и кода — набора инструкций, обрабатывающих эти данные. Такое деление четко прослеживается как в ассемблерном коде, так и в процедурных языках.

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

Правильный код в стиле ООП разделяет объекты-данные и объекты-сервисы. Первые (сущности, объекты-значения и т. д.) — обобщение понятия структуры. Вторые — обобщение понятия процедуры и функции.

Читайте о правильном подходе в статье Дмитрия Елисеева «Структуры с процедурами или объекты?». Он подробно разобрал тезис о разном применении разных типов объектов и проиллюстрировал всё на примерах для PHP.

Электронная медицинская карта и утечки

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

Зашел, посмотрел. Есть данные из «районной» поликлиники. Из частных поликлиник — нет.

И вот о чем еще подумал: в свете новых методов расследования, примененных к отравлению Навального, насколько легко получить доступ к базам медицинских карт?

Связь между физикой и программированием: абстракции и язык — В кресле препода №6

Я заметил нетривиальную связь между физикой и программированием. Она находится в области используемых и там и там абстракций и обозначений. Записал видео с объяснением и примерами.

Придумал название «В кресле препода» для таких видео, где я обсуждаю какие-то вопросы и делюсь опытом. Встречайте выпуск №6.

00:00:47 Зачем слушать этот рассказ
00:01:33 Замечание о формате презентаций
00:03:15 План рассказа
00:04:01 Математический аппарат физических теорий
00:05:39 Механика Ньютона и двойной маятник
00:09:45 Уравнения Максвелла: векторная и компонентная форма записи
00:14:17 Четырехвекторы и скорость света
00:18:01 Принцип наименьшего действия
00:21:25 Разнообразие форм уравнений Максвелла
00:23:41 Причем здесь программирование?
00:28:28 Уровни абстракций в языках программирования: физический, процедурный, ООП
00:33:26 Кто создает больше абстракций: физик или программист?
00:37:23 Практический пример
00:41:21 Разбор примера обработки тач-событий из MDN
00:48:50 Переписывание примера из документации в объектном стиле и добавление функциональности на примере головоломки Арнольда (исходник на гитхабе)
01:17:58 О «пользе» MVC и что такое ООП на самом деле
01:20:35 Сравнение процедурного и объектного подходов и принцип High Cohesion Low Couping
01:23:42 Наследования и полиморфизма нет, а дух ООП есть

Описание головоломки Арнольда в предыдущем посте и на хабре.

Головоломка Арнольда ★

Постоянные читатели помнят, что мы с коллегами по учебе лет 10 назад занимались задачей Арнольда. В ней остались открытые вопросы, и я недавно решил к ним вернуться. Дописал одну из программ, отрисовывающих и распрямляющих конфигурации, и понял, что получилась хорошая игровая механика для головоломки. Переписал код визуализации и моделирования на js, и получилась браузерная головоломка.

Правила

В этой игре выполняются простые правила:

1. На плоскости проведены несколько линий, каждая пара линий пересекается в одной точке.
2. Линии разбивают плоскость на области, раскрашенные в шахматном порядке.
3. Вы можете перестраивать разбиение, «схлопывая» и «выворачивая» треугольники.
4. Ваша цель — получить максимально возможное количество темных областей.

В простейшем случае 5 линий процесс игры выглядит так:

Пользовательский опыт

При небольшом количестве линий решить головоломку можно случайным перебором. Нужно помнить, что иногда надо «пожертвовать» счетом (количеством темных областей), так как не всегда есть «прямая дорога» к цели, на которой счет только увеличивается.

Я довольно быстро «прошел» все уровни до 19 линий. 21 линию (на скриншоте в начале) собрал часа за полтора. Правда, я знал, что существует вращательно-симметричная конфигурация (поворот на 120° переводит ее в себя), и специально делал ее симметричной. 23 линии пытался собрать дважды, и оба раза не получилось набрать последнее очко.

С увеличением уровня сложность игры растет не только количественно (нужно дольше идти к цели), но и качественно: приходится придумывать новые приемы и подходы, так как старых становится недостаточно.

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

Игра полностью отвлекает от происходящего вокруг, подходит для убивания времени в метро.

Математическая основа

Напомню формулировку задачи Арнольда:

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

Это открытая математическая проблема. Она является частным случаем 16-й проблемы Гильберта для многочленов специального вида — произведения линейных сомножителей ax+by+c.

Таким образом, переворачивая треугольники в головоломке, вы на самом деле решаете в частном случае 16-ю проблему Гильберта! :)

Для преобразования конфигураций в головоломке именно схлопывание треугольников выбрано не случайно. Оказывается, с помощью таких схлопываний можно перевести произвольную конфигурацию в любую другую конфигурацию. Действительно, линии на плоскости, описанные в правилах, называются конфигурацией (псевдо)прямых. Они представляют элемент из группы кос. Суть теоремы Артина об образующих группы кос как раз и состоит в возможности перевода конфигураций друг в друга последовательностью преобразований треугольников.

Также задача Арнольда тесно связана с задачей о треугольниках Кобона.

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

Вычислительная модель игры

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

Рубаков

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

Не совсем интервью, правда. Из видео вопросы вырезали, добавили текст при монтаже. Но всё равно тут главное послушать Рубакова.

Понятие формата в дизайне интерфейсов — В кресле препода №5

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

Когда формулировал, почему моим словам стоит доверять, осознал, что у меня уже почти 13 лет опыта в коммерческой веб-разработке. Незаметно время летит :)

00:11 Почему моим словам стоит доверять: 13 лет опыта
00:42 Собирался рассказать о понятии формата давно
01:11 Для затравки: чем плохи выпадайки в вебе, пример личного кабинета интернет-банка
03:28 Понятие формата
04:56 Пример 1: формат веба и формат окон настройки старых операционных систем (сравнение из старой статьи на хабре)
08:03 Комментарий к статье, обращающийся к понятию формата
10:42 OS/2 умер
12:09 Окно настройки — почему такое? Ограничение 1: физический размер экранов
14:24 Ограничение 2: размер видеопамяти
15:26 Ограничение 3: частота обновления
18:53 Ограничение 4: работа без драйверов
19:54 640*480 — естественное ограничение в конце 90-х
20:58 Особенности формата веба
22:47 Сравнивать надо функциональность
25:28 Бессмысленность претензий к вебу
26:52 Эволюция интерфейса настройки Windows
32:28 Пример 2: Одностраничные приложения
33:54 Админка моего движка как пример одностраничного приложения
37:25 Как бы сейчас спроектировал интерфейс админки
41:42 Обсуждаем извлеченные уроки и дизайн выпадайки из личного кабинета интернет-банка
46:17 Итог

Главное правило подготовки докладов

Научный руководитель в свое время открыл мне главное правило подготовки докладов на выступлениях.

Доклад нужно разделить на три примерно равные части. Первую часть доклада должны понять все присутствующие. Вторую часть — около половины. Третью часть должны понимать всего несколько человек.

Вы вольны выбирать структуру доклада самостоятельно. Пример: вы придумали решение какой-либо проблемы. Вариант структуры:

1. Описание проблемы, обзор существующих методов решения.
2. Поиск решения: предпосылки, логические построения, гипотезы, неудачные варианты.
3. Технические детали решения.

Недавно со мной советовались, как подготовить доклад. Я вспомнил это правило и посоветовал его. Доклад получился замечательным.

Уборка улиц, отрицательная польза и коррупция

Выглянул в окно и увидел, как дворник заметает мусор под припаркованные машины. Сходил за мобильником и начал снимать. Он перестал сметать мусор под машины, но стал — на газон. После фотографировал чистый асфальт. А под конец перекинул мешок с мусором через ограждение вырытой ямы, хотя до мусорных баков было метров 10.

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

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

Латынина об этом говорила не один раз:

У нас до сих пор через железнодорожные переезды вокруг Москвы не построены нормальные автомобильные переезды, у нас автомобили стоят в пробке по несколько часов. При этом рядом как всегда таджики косят траву, нанятые, видимо, Железной дорогой.

То есть вот это вот… Извините, что я постоянно возвращаюсь к этим косящим траву таджикам. Но это такое абсолютно зримое воплощение принципа о том, что если вы хотите украсть, то чем более бесполезна работа, которую выполняют люди, тем больше вы можете украсть. Потому что, ну, понятно: если таджики косят траву, то на этом украсть можно больше, чем если даже те же таджики (я уж не говорю о том, чтобы русские рабочие) построили переезд через эту несчастную железную дорогу.

Яндекс-рай

← сюда туда →