В прошлой статье говорилось про общую постановку проблемы. Теперь пришло время обсудить её общее решение.
Терминология
В законах Авто-всего будет фигурировать термин «продукт». Не хочу особо вдаваться в объяснение термина, скажу только, что продукт, это то, что появляется в результате человеческой деятельности. Продукт – не обязательно материальная ценность, он может быть идеей, литературным произведением, научным законом и так далее. Главное, что продукт – это результат труда человека и, собственно, то, ради чего труд и затевается.
После своего изготовления продукт поступает от производителя к потребителю, который не обязательно будет конечным потребителем. Вполне возможно, что потребитель воспользуется продуктом как инструментом или компонентом для производства. Инструмент – это то, с помощью чего делают. Компонент – то, из чего делают.
Каждый продукт подразумевает некоторое количество действий, которые над ним или с его помощью можно совершить. Действия, совершаемые потребителем, требуют усилий с его стороны.
Законы предельной автоматизации
1. Любой продукт делается для людей.
2. Использующий продукт как компонент ничем не хуже того, кто использует его как инструмент.
3. То, что может быть автоматизировано, должно быть автоматизировано.
4. Наиболее распространённое действие должно требовать минимального количества усилий со стороны потребителя. В идеале – ни одного.
5. Если несколько действий конкурируют за право быть наиболее распространёнными, то должно минимизироваться суммарное количество усилий на эти действия.
6. Каждое действие должно предусматривать значения параметров по умолчанию, если это в принципе возможно.
7. Значения параметров по умолчанию следует пытаться угадать, исходя из контекста и других, уже заданных параметров.
8. Чем более распространено действие, тем меньших знаний о продукте со стороны потребителя оно должно требовать.
Разъяснения законов
1. Любой продукт делается для людей.
Первый закон – это основной постулат предельной автоматизации. Он задаёт цель всему процессу и одновременно обосновывает его важность. Действительно, зачастую разработчики забывают, что сделанный ими продукт, он не просто так, а для использования его другими людьми. Так программист считает, что он пишет программу для компьютера. Рабочий – что он делает деталь для автомобиля. Педагог – что он пишет учебник для школы.
Всё так, программа для компьютера и учебник для школы. Однако самое главное, что всё это – для людей. Пользоваться программой будет человек, а не компьютер. Компьютер будет её только исполнять. Учебник будут читать школьники, а роль школы в том, чтобы этот учебник распространить. И так далее.
Когда производитель забывает о мысли «продукт – для человека», продукт очень часто получается к употреблению не годным. Хотя формальному своему определению он может вполне соответствовать. То есть, программу таки компьютер исполнить сможет.
Этот, наиболее важный закон следует постоянно держать в голове. Каждый элемент дизайна, каждый нюанс конструкции должен обязательно примеряться на потенциального потребителя.
2. Использующий продукт как компонент ничем не хуже того, кто использует его как инструмент.
Несколько более редкой ошибкой, чем нарушение первого закона, является мнение, будто продукт, предназначенный в качестве компонента, не так важен, как продукт-инструмент. Конечный пользователь – это пользователь инструмента. Поэтому кажется, будто в результате труда цепочки производителей должен получиться хороший инструмент, а проблемы каждого следующего производителя в цепочке предыдущего волновать не должны. Дескать, не дураки, сами разберутся.
Такой подход часто исповедуется разработчиками программных библиотек. Библиотека – компонент программы, а не конечный продукт, из-за этого кажется, что библиотеку причёсывать не надо. А если использующему библиотеку она кажется неудобной, то это только потому, что «ламер не разобрался». Со временем программисты к такому подходу привыкают и машинально переносят его на конечного пользователя тоже. «Это же только конченные дебилы не знают, что когда вон в тех дебрях настроек стоит вот эта галочка, то мой мощный текстовый процессор игнорирует нажатия всех клавиш». «Даже барану должно быть понятно, что для открытия файла при запуске моей программы из консоли надо ввести –opnfl /a –mode rd-wr dt=cur». «В инструкции же всё написано – на 2053-ей странице в левом нижнем углу».
Однако если для конечного пользователя такие проблемы фатальны, то производитель, использующий продукт как компонент для производства нового продукта, наверняка всё это сможет пережить. В случае чего он произведённое мной колесо напильничком подточит и оно как влитое встанет. И семигранный ключ, которым колесо привинчивается, где-нибудь отыщет.
В чём результат такого подхода? В экспоненциальном росте стоимости производства. Производитель первого компонента в цепочке мог бы сделать его удобнее ценой нескольких часов своего времени. Второй производитель цепочки тратит на приведение компонента к требуемому виду – дни, причём, так делают все вторые производители. Не исключено, что третьим понадобятся месяцы на исправление проблем. Нет, они не дураки, они справятся. Но какой ценой?
При изготовлении продукта следует думать не только о конечных пользователях. Каждый следующий работник производственного конвейера – тоже пользователь. И он ничем не хуже конечного потребителя.
3. То, что может быть автоматизировано, должно быть автоматизировано.
После первых двух законов, задающих наиболее общие цели процесса, следует первый закон-рекомендация. Она говорит, что если автоматизация возможна, то она и необходима тоже. Усилия на автоматизацию со стороны производителя окупятся их отсутствием у пользователей. Не надо заставлять пользователей делать рутинные действия, если их можно и не делать. Пусть пользователь займётся чем-то другим. В частности, другим производством. В совокупности так выгоднее.
«Мы заставляем пользователя совершать действия, в которых нет необходимости, чтобы повысить его квалификацию» – это отговорка. Рутина не повышает квалификации. Особенно если учесть, что потребителю обычно полезнее повышать квалификацию преимущественно в области его деятельности, а не в иных сферах. Конечно, не очень здорово, когда потребитель не даёт себе труда прочесть инструкцию и разобраться в деталях. Но вспомним, какое количество приборов и программ ежедневно использует современный человек. Тысячи их! Инструкция на двадцать страниц к каждому прибору – это десятки тысяч страниц в сумме. Не то, что запомнить, прочитать проблематично. Не факт, что именно ваш прибор будет самым важным и самым нужным. Однако даже если он не самый важный, он должен оказаться полезным в использовании. Для этого прибор следует по максимуму автоматизировать. Точнее, не сам прибор, а действия, которые над ним или при его помощи совершаются.
4. Наиболее распространённое действие должно требовать минимального количества усилий со стороны потребителя. В идеале – ни одного.
Что же подразумевается по автоматизацией, о которой говорит последний абзац предыдущего пункта разъяснений? Четвёртый закон как раз и расшифровывает это понятие.
Каждый продукт подразумевает некоторые сценарии использования. То есть, в текстовом процессоре наверняка будут набирать текст. На автомобиле – ездить. Телевизор – смотреть. И так далее. Каждое из озвученных действий – основной сценарий. Соответственно, им будут чаще всего пользоваться. Это, в свою очередь, будет тем действием, которое совершают все – и те, для кого данный продукт – самый важный, и те, кому он нужен лишь эпизодически.
Если посчитать суммарное количество усилий на каждое действие, возможное к совершению посредством продукта, то наиболее распространённые действия окажутся наиболее же критичными к усилиям, требуемых на их выполнение.
Положим, некоторое действие требует некоторых усилий и аналогичных же требует другое действие. Однако первое действие из расчёта на месяц выполняется в тысячу раз чаще второго. Первое действие тогда отнимет в тысячу раз больше сил у пользователей, нежели второе. Из этого очевидно, что уменьшить усилия в первую очередь надо именно в приложении первого действия.
В идеале, конечно, следует уменьшить усилия на все действия, однако некоторые из них противоречат друг другу. Например, затруднительно у телевизора включить все каналы сразу – следует выбрать только один. Однако хотя бы один следует выбрать. Ведь обычно телевизор включают не просто так, а чтобы смотреть какой-то канал. Следовательно, наиболее распространённым действием будет именно выбор канала. Как тут быть? Логичный вариант – выбрать тот канал, который был выбран перед выключением. Это уже будет минимизацией усилий по сравнению с требованием к пользователю выбрать канал после включения в обязательном порядке и даже по сравнению с выбором первого канала в списке.
Однако это – первый шаг. По хорошему надо бы собирать статистику частоты использования каналов и сортировать каналы по убыванию этой частоты. Тогда при включении автоматически выбирается тот, который смотрели перед выключением, а специальные кнопки пролистывания каналов позволят пролистывать их не по физическому порядку, а по статистике использования. Если человек смотрит преимущественно два-три из тридцати, то такой подход существенно уменьшит требуемое от него количество усилий. Вместо пролистывания каналов по порядку или попыток вспомнить один из тридцати номеров, требуемый канал будет выбираться максимум двумя нажатиями.
Аналогичным образом можно поступить с музыкальными центрами. Зачем, спрашивается их включать перед нажатием кнопки «play»? Да ни зачем. Об этом просто никто не думает. Более того, никто не думает даже о том, что кнопка включения/выключения вообще не нужна на музыкальном центре. Центр должен включаться по кнопке воспроизведения и сразу начинать играть с того места, где остановились. Выключаться же он должен без вмешательства пользователя – просто по отсутствию активности в течении пяти минут. Количество бесполезных действий, связанных с бытовыми приборами, ощутимо выходит за грань разумного.
Но ещё сильнее выходит за эту грань количество действий, требуемых для выполнения простейших операций при помощи всевозможных программных библиотек. Иногда вообще складывается впечатление, что разработчик ни разу не задумывался над тем, как его библиотеку будут использовать. Казалось бы, есть библиотека, предоставляющая некоторый набор действий с файлами. Наиболее, так сказать, общий. Какие действия с ними будут делать? Читать из них, писать в них, копировать, создавать, удалять. Файлы наверняка будут складывать в папки, для которых не менее наверняка будет предусмотрено копирование, создание и удаление. Почему, интересно, разработчики библиотек считают ценными исключительно первые два? И то – только для файлов? Почему нет очевидных команд копирования, создания и удаления для файлов и папок прямо в библиотеке? Ответ: потому, что предусмотрены наиболее общие действия. Остальные – из них выводятся.
Не надо заставлять пользователя выводить часто употребимые действия их других. Это редкие действия должны выводится из частых. Удалить папку, в которой есть другие файлы и папки – это очень часто встречающееся действие. Оно должно выполнятся одной командой.
Когда речь заходит про основные сценарии использования, часто можно слышать «но мы же не знаем, что пользователь захочет сделать!». А надо знать. Продукт, сделанный из расчёта «я ничего не знаю о желаниях пользователя», совершенно бесполезен. И наоборот, чем больше вы знаете о желаниях пользователя, тем больше шансов сделать удобный в использовании, полезный продукт.
Исходя из этого, разработка продукта в обязательном порядке должна начинаться с вычленения основных сценариев использования и наиболее распространённых действий. Продукт должен разрабатываться в первую очередь в расчёте на максимальную простоту и удобство их выполнения. Остальные варианты использования (в том числе наиболее общие) для наиболее одарённых и въедливых тоже вполне можно оставить. Но они никак не равноценны с наиболее распространёнными.
По мере разработки следует внимательно следить, а не нарисовался ли ещё какой-то вариант, который был не учтён в начале, но наверняка будет часто использоваться. Если такой обнаружился, его надо сразу же включить в список. И поправить под него разработанное ранее.
5. Если несколько действий конкурируют за право быть наиболее распространёнными, то должно минимизироваться суммарное количество усилий на эти действия.
Пятый закон является дополнением и уточнением четвёртого. Как было сказано выше, некоторые действия конкурируют друг с другом и не всегда возможно угадать, какое будет использоваться чаще.
Например, мы можем предположить, что некоторые пользователи музыкальных центров при включении их захотят продолжить прослушивание не с того места, где они остановились, а с начала песни. Возможно, их будет ровно столько же, сколько желающих послушать с того же места. Очевидно, что нельзя одновременно запустить песню с начала и с середины, поэтому надо выбрать один из вариантов.
Конечно, в данном случае можно сделать некоторую настройку, которую будет задавать пользователь по своему вкусу. Но и это не спасает. Например, одним музыкальным центром могут пользоваться два человека, взгляды которых отличаются. Более того, возможно, один и тот же человек в разных случаях делает по разному. То есть, наиболее распространёнными являются оба варианта в равной степени и выбираться они должны «на лету́». Как быть?
Для начала надо посмотреть, сколько усилий понадобится для реализации одного из действий, если по умолчанию сработает второе.
Так, если воспроизведение по умолчанию начинается с начала песни, то для продолжения прослушивания с момента остановки пользователю надо:
1. Вспомнить место, где воспроизведение остановилось. Очень и очень затруднительно.
2. При старте воспроизведения с начала песни, нажать кнопку перемотки и домотать до искомого места. Либо же ввести искомое время с пульта управления. Чуть менее сложно, чем запомнить, однако требует неадекватного задаче времени на выполнение.
Если же воспроизведение началось с места остановки, то для перехода к началу песни надо просто нажать кнопку «на начало трэка». Быстро и просто.
Приведённый анализ нам показал, что суммарные усилия на равноценные по распространённости действия в разы меньше при реализации второго варианта поведения – старта с места остановки. Следовательно, именно этот вариант надо реализовать.
Конечно, есть и другой, очень близкий по суммарным усилиям вариант – старт с начала трэка при наличии кнопки «продолжить с места предыдущей остановки». Но для пользователя он гораздо менее очевиден.
Данный закон можно обобщить на все действия, которые можно выполнить при помощи продукта. Для этого частоту произвольного действия следует принять за единицу, а частоты остальных действий выразить в отношении к выбранному. Минимизироваться в таком случае должна сумма произведений частот действий на соответствующие им усилия.
6. Каждое действие должно предусматривать значения параметров по умолчанию, если это в принципе возможно.
Шестой закон – ещё более частный. Он говорит о том, что подразумевается под минимизацией усилий.
Каждое действие можно представить как задание некоторого набора параметров. Этими параметрами может быть что угодно – последовательность нажатых кнопок, поля некоторой формы, вызовы методов в программе. Соответственно, подразумевается, что для выполнения действия надо задать полный набор требуемых для него параметров.
Однако зачастую не требуется задавать все параметры каждый раз. Например, для просмотра телевизора не обязательно при каждом включении заново настраивать каналы, подстраивать яркость и контраст, устанавливать время и, как уже говорилось выше, выбирать канал. В большинстве случаев достаточно того, что когда-то в прошлом всё уже было настроено.
Аналогичным образом при создании окна приложения в операционной системе в большинстве случаев создаются окна из типичного их набора. Этот набор весьма невелик, в него входит три-четыре варианта, а все остальные используются в редких и специфических случаях. При этом API позволяет менять десятки, а то и сотни параметров окон. Возникает логичное предположение: надо предусмотреть возможность создавать эти три-четыре варианта одной командой, не требуя ввода сотен параметров при их создании. Но если эти параметры необходимы, то откуда же они тогда возьмутся в реализации данных команд?
API – это набор команд для взаимодействия приложения с другими приложениями.
Ответ, в общем-то, очевиден: из предустановок. То есть, из наборов параметров по умолчанию. И такой подход обязателен к использованию во всех системах, следующих концепции Авто-всё.
Для любого параметра следует предусмотреть значение по умолчанию. Например, через наборы предустановок. Предустановки должны быть подобраны таким образом, чтобы наиболее частые действия охватывались ими. Чуть менее частые должны требовать ввода небольшого количества параметров, причём, допускать ввод их по отдельности. Полный же набор следует требовать только для специфичных действий, которые невозможно предугадать на этапе разработки и даже – на этапе эксплуатации.
Неследование этому закону напрямую нарушает практически все предыдущие, требуя постоянно вводить совершенно ненужные, стандартные параметры при каждом использовании продукта, что радикально увеличивает усилия, требуемые на совершения стандартных же, наиболее распространённых действий.
Анкеты требуют в явном виде писать «не состоял», «не имел», «не участвовал». Да, это для безопасности – чтобы посторонние туда что-то другое потом не вписали. Но ведь достаточно, например, перечеркнуть вопрос.
Вообще в целом ряде случаев проще требовать отмены действия, а не его совершения. Например, в языке программирования Java каждая команда должна оканчиваться точкой с запятой. При этом количество мест, где точка с запятой может встретится в другом месте исчезающе мало – это цикл «for» и строки символов. По этой причине среда разработки Eclipse автоматически переносит точку с запятой в конец строки, если она введена не в строке символов или в скобках цикла «for». Чтобы вернуть её обратно, надо нажать backspace, однако сделано такое скорее для перестраховки – оно практически никогда не требуется. Зато угадывание подобного рода экономит драгоценные миллисекунды, на протяжённых промежутках времени выливающиеся в часы и дни. Самое главное, это угадывание бережёт нервную систему.
Значением параметра по умолчанию, в том числе, является устранение кнопки включения музыкального центра. Да, чтобы заиграла музыка, надо центр включить. Однако при вдумчивом анализе становится ясно, что этот параметр можно задавать по умолчанию вообще во всех случаях: если введена любая команда, то надо включать, если активности некоторое время нет – надо выключать. Всё просто.
Из этого же закона вытекает концепция стандарта. Если, например, прибор предусматривает питание от сети, то разумно сделать его вилку подходящей к стандартным розеткам. Конечно, нет никакой гарантии, что у потребителя розетка – именно что стандартная. Но раз уж стандарт розеток есть, то наверно у большинства потребителей именно такие. И для них будет наименее затратно воспользоваться прибором со стандартной вилкой. Для остальных можно предусмотреть переходники, но по умолчанию используется стандарт.
Непредусмотрение стандартов приводит к ряду печальных катаклизмов. Например, не весь мир ещё перешёл на стандартную систему мер. Не все ещё даже длину измеряют в метрах. А несколько раньше, так чуть ли не каждый район планеты использовал свои системы мер. Из-за этого куча усилий уходила на перевод из одной системы в другую, что в дополнение порождало множество ошибок.
Английские розетки предназначены для вилок с тремя штырьками. При этом отверстия для двух из них открываются только после того, как третий штырёк войдёт в предназначенное для него отверстие. Из-за этого вилки от российских приборов в розетки не влезают. Решается проблема при помощи карандаша, который вставляется в отверстие для третьего штырька. Англичанам в России сложнее – их вилки в наши розетки без переходника вообще не влезут.
Аналогичным катаклизмом обернулось отсутствие стандартной строки в языке С++. Строка, конечно, в настоящее время поставляется со стандартной библиотекой, однако изначально эта библиотека была сторонней разработкой, а унаследованный из С метод использования строк через указатели на char был крайне неудобен в использовании из-за своей необъектной природы. Такое положение вещей привело к десяткам, а то и сотням, реализаций строк, разошедшихся по тысячам библиотек. В результате усилия программистов уходили и продолжают уходить на поиски способов преобразования одних строк в другие. То же самое произошло с наиболее распространёнными контейнерами – списками, картами, множествами. Отсутствие их в стандартной поставке языка вынудило программистов писать свои реализации всего этого, а конвертация разных реализаций списков и карт, она посложнее конвертации строк будет. Результат? Многие и многие человеко-годы, потраченные на написание повторяющихся по сути кодов и систем конвертации между ними. Введение же строк с контейнерами в стандарт и использование их по умолчанию сэкономило бы кучу сил и времени.
7. Значения параметров по умолчанию следует пытаться угадать, исходя из контекста и других, уже заданных параметров.
Ещё более продвинутым вариантом подбора параметров по умолчанию, нежели предустановки, является анализ контекста использования. Рассмотрим, например, анкету:
1. ФИО
2. Пол
3. Семейное положение
Создатель анкеты предполагает, что анкетируемый в обязательном порядке должен заполнить все поля. Это ещё до какой-то степени осмыслено, если анкету будет анализировать человек – заполнение всех полей минимизирует его усилия, но если анализирует компьютер, то заполнение всех полей в обязательном порядке – явный перебор.
Например, легко догадаться, что у человека с фамилией «Иванов» пол мужской. В тех гипотетических случаях, когда фамилию Иванов носит женщина, она может указать пол в явном виде, но в остальных можно ведь догадаться по контексту.
Аналогичным образом не имеет смысла писать женат/замужем, холост или разведён. Один вариант можно предположить по умолчанию. Особенно в том случае, когда «холост» и «разведён» – тождественны.
Итого, в наиболее распространённом случае нельзя угадать только фамилию, имя и отчество. Остальное – угадывается. Пол угадывается почти наверняка, а «семейное положение» можно без потери общности заменить, например, на «состою в браке» и квадратик для галочки рядом с ним – «женат» ведь или «замужем» угадывается по полу.
Это оно пока что угадывается по полу...
Другим примером угадывания параметра по контексту может служить окошко для ввода даты. Всё равно, что за дата имеется в виду. Какие даты мы можем угадать из общих соображений, если не задано ничего другого? Текущую. Да, не исключено, что человеку нужно ввести иную дату, однако задание по умолчанию текущий – наилучший выбор из возможных. Ведь другие даты мы угадать никак не можем. С другой стороны, если вдруг потребуется ввести текущую дату (или даже отсчитать от неё), то человеку придётся лезть в календарь. Если же её вывести по умолчанию, то мы облегчим человеку задачу – дадим ему точку отсчёта. Это – как минимум. Отсчёт же от текущей даты в большинстве случаев проще в смысле усилий, нежели отсчёт, например, от первого января первого года.
При кажущемся разнообразии вариантов, многие наборы параметров содержат массу избыточной информации. Концепция Авто-всё призвана освободить пользователя от ненужной работы, позволив ему задавать только то, что вычислить из других параметров нельзя.
8. Чем более распространено действие, тем меньших знаний о продукте со стороны потребителя оно должно требовать.
Наконец, восьмой закон концепции накладывает ограничения не только на усилия потребителя, но и на набор необходимых ему знаний. Если потребитель не собирается чинить музыкальные центры, ему совершенно необязательно знать, каким образом заменяются в них конденсаторы. Если потребителю требуется создать обычное окно с помощью оконной библиотеки, ему не надо вдаваться в нюансы взаимодействия библиотеки с операционной системой. Распространённое действие требует минимальных знаний.
Пусть потребитель потратит время на что-то более полезное, нежели изучение нюансов продукта, которым он пользуется раз в год. Не исключено, у эпизодического пользователя есть масса других областей, в которых он может проявить свой талант.
Точно так же, использующий продукт каждый день, должен в первый же день использования просто взять и начать использовать продукт. Метод познания через практику приносит гораздо более впечатляющие результаты. Если для запуска программы следует прочесть мануал, сравнимый с полным собранием сочинений Ленина, большинство людей просто не станут её запускать. И наоборот, сложная программа со множеством возможностей, но позволяющая сделать с её помощью что-то простое при первом же запуске, программа, постепенно увеличивающая свои требования к знаниям пользователя, привлечёт к знаниям о ней гораздо больше людей. Не говоря уже о том, что просто гораздо больше людей будут её использовать.
Надо отметить, что подход, озвученный в данном законе, вызывает наибольшее количество возражений. Зачастую люди боятся, что упрощение наиболее распространённых действий превратит пользователей в «тупых юзеров». Отчасти подобное предубеждение вызвано подсознательным страхом, что пользователь не оценит всей глубины идей, заложенных в продукт. «Тупой юзер» сразу ринется ездить на нашем автомобиле и никогда не узнает, как ловко мы совместили зажигание с прикуривателем. Никогда не увидит диалог, над которым мы бились полмесяца. Не узнает, как ловко можно написать скрипт на придуманном нами языке, а будет просто тупо тыкать в графические элементы интерфейса. Ну и так далее.
На это я могу только повторить то, что уже сказал: не надо думать, что тупой поумнеет от вашей программы. Не надо думать, что порождённые вашим расчётом на «умного пользователя» приложения, заставят пользователя поумнеть. Поумнеть его если что-то и заставит, то только программа, которая к нему дружелюбна. Которая не посылает его при каждой ошибке в баню, а рекомендует способы борьбы с ошибками. Которая стимулирует ей пользоваться, благодаря доставляемому удовольствию от её использования. Что подвигает на более глубокое изучение её возможностей.
От неудобной программы, выкатывающей при старте целый набор требований к изучению нюансов, плюются не только «тупые юзеры», от неё и умные тоже плюются – им-то ведь не только неудобно, им ещё и понятно, практически даже очевидно, как можно было сделать удобнее. Итого расчёт на избыточные знания отталкивает и тупых и умных. Привлекает разве что любителей выпендриться на ровном месте. Да и те станут разбираться в программе только для того, чтобы потом, где-нибудь на форуме написать, как круто они во всём разобрались.
Пользователь должен круто разбираться не в сделанном производителем. Пользователь должен круто разобраться в решаемой им, ранее никем не решённой задаче. В этом состоит экономия совокупных сил человечества. Уже решённое же следует обрамлять в удобную для использования и изучения форму.
Читайте в следующих выпусках:
Кинг-конг, Годзилла или Авто-форма – Кто кого заборет в честном бою?
От чёрного прямоугольника к нагромождению штрихов и красок – Как разработчики интерфейсов переплюнули сюрреалистов
«Я умею читать объекты» – Интервью с Авто-формой
Британские учёные разработали кнопку «зафигарить» – Миллионы дизайнеров ожидают увольнения
← Ctrl ← Alt
Ctrl → Alt →
← Ctrl ← Alt
Ctrl → Alt →