Ctrl + ↑ Позднее

Интересный отзыв к книге на Амазоне.

Книга:
The Language of Things: Understanding the World of Desirable Objects
https://www.amazon.com/Language-Things-Understanding-Desirable-Objects/dp/0393070816/ref=pd_sim_14_2?_encoding=UTF8&pd_rd_i=0393070816&pd_rd_r=WS56554CFB527HV255YC&pd_rd_w=BcEYR&pd_rd_wg=j6EWD&psc=1&refRID=WS56554CFB527HV255YC

В частности: «…автор начинает с жалобы: купил компьютер Эпл, потому что он был симпатичным и сочным (вероятно, речь идет об аймаке с цветным пластиковым корпусом). Позже он обнаруживает, что симпатично и сочно — это не функционально. Поэтому он покупает черный и плоский компьютер Эпл, потому что тот был черным и плоским. И позже понимает, что черный цвет и плоская форма не говорят о функциональности…».

Ссылка на отзыв:
https://www.amazon.com/Language-Things-Understanding-Desirable-Objects/dp/0393070816/ref=pd_sim_14_2?_encoding=UTF8&pd_rd_i=0393070816&pd_rd_r=WS56554CFB527HV255YC&pd_rd_w=BcEYR&pd_rd_wg=j6EWD&psc=1&refRID=WS56554CFB527HV255YC

Оутс Студиоз, Нил Бломкамп

Интересные штуки снимает режиссер Нил Бломкамп и Оутс Студиоз (Oats Studios). Остроумные короткометражки в жанре фантастики. Будет интересно тем, кому понравились «9 район» и «Чаппи». Выкладывают бесплатно на канале в Ютубе:
https://www.youtube.com/user/OatsStudios/videos

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

Интервью Нила:

Любопытен подход: снимать малыми частями, выкладывать бесплатно, дать возможность заплатить при желании, наблюдать за реакцией зрителей.

Мне кажется, это талантливо, смело и интересно. Поэтому я пересмотрел всё.
А вам как?

Как менял кольца на спиннинге

Опыт в моделизме помогает в рыбалке :-) Сломал на своем любимом компактном спиннинге верхнее кольцо, «тюльпан». Со сломанной вершинки слетело и потерялось и скользящее разгрузочное кольцо. Жалко, удобная штука для поездок. И недешевая. Надо чинить.

Сломанная вершинка выглядит так:

А должна так:

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

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

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

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

Замешиваю 2 мл смолы с 1 мл отвердителя L285. Время до вязкости примерно 40 минут. Обязательная вентиляция в помещении. Поверх полиэтилена мотаю кевлар со смолой, затем добавляю колечко и мотаю еще кевлара. Удаляю излишки смолы. Сверху обтягиваю еще полоской полиэтилена. Ставлю на ночь в теплый короб в ванной, где проходят трубы горячего водоснабжения. При повышенной температуре смола застывает быстрее и лучше. В результате скользящая втулка с кольцом точно соответствует толщине хлыстика. Хлыст 1.1 мм, а у кольца посадочное 1.4 мм. Чтобы село плотно, намотаю пару слоев кевлара со смолой.

Готово. Должно держать до 7 кг. Ближайшее тестирование — на адриатическом побережье :-)

Скользящее кольцо:

Экономика, история и изолированные события

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

Также нельзя наверняка сказать, что определенное событие привело к определенному изменению в экономике. Мы не видим всех факторов, влияющих на экономику в реальном мире. Нельзя определенно сказать: произошло событие «А», и поэтому в экономике произошло «Б». Конечно, событие «А» могло повлиять на «Б», но влияние «А» могло быть и минимальным по сравнению с невидимыми факторами.

Цепочка влияния: например, событие «А» повлияло на возникновение события «Б». Можно сделать вывод, что, синтезируя событие «А», мы получим «Б». И снова это нельзя сказать наверняка: к событию «А» привели какие-то другие предпосылки, где «А» было только видимым симптомом. Если воссоздать симптом «А» с чистого листа, нет и близко никакой гарантии того, что оно приведет к «Б».

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

А → Б

Но ошибочно полагать, что «А» обязательно изолировано. В реальном мире «А» не изолировано от контекста:

... → А → Б,

и, в более общем случае,

... → [А, нечто 1 ... нечто N] → Б

Поэтому, в случае синтезирования изолированного «А»:

А → ... получается неизвестно что.

Примеры, в разных масштабах:
— Копирование диеты, которая помогла другому человеку.
— Народные приметы и суеверия: с какой ноги вставать, сколько раз пропела кукушка.
— Поверхностное копирование компаниями моделей управления других компаний — всё равно что красить волосы вместо изменения ДНК.
— Попытки «экспертно» решить проблемы одних стран, глядя на другие, без учета истории стран.

Картинка с сайта http://www.collectorsweekly.com

Упражнение для пилота

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

Кладбище Монмартр, Париж

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

Дизайн, тестирование, ошибки и логика

Хороший дизайн создается с учетом обратной связи. Для этого решение тестируют уже в процессе создания и по готовности в реальных условиях. Обратная связь помогает понять, хорош ли дизайн, правильно ли работает решение.

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

Две крайности:
1) Дизайнер делает продукт совсем без обратной связи.
Полагается на то, что «всё знает» с самого начала, и продукт будет вести себя именно так как задумано на всем протяжении процесса использования.

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

2) Дизайнер делает продукт, полагаясь только на обратную связь.
Допустим, тестирование пользовательского взаимодействия выявило проблему П1. А проблему П2 не выявило. Может быть, проблемы П2 не существует. А может быть, тестирование обошло эту проблему стороной. Дизайнер думает: «проблемы П2 не существует».

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

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

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

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

Дизайн и тестирование это два разных процесса. Хорошо, когда они дружат и понимают задачи друг друга, сильные стороны и цели. Но это разные процессы, и задачей «тестирование» невозможно закрыть или подменить задачу «дизайн» по определению.

* * *

Простая, но важная логическая конструкция:

Отсутствие доказательства не является доказательством отсутствия.

Практика показывает, что эта мысль известна и понятна не всем. Это приводит к сложностям.

Логическая ошибка, основанная на описанной выше ошибке №2: Ответственный за результат человек предлагает решение. Человек с правом вето, например, заказчик или руководитель, отклоняет: «Мы тестировали продукт, такой ошибки не обнаружено. Это для нас не критичный момент».

Связь обнаруженного симптома и исходной проблемы не всегда прямая и очевидная.

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

Что-то подобное, хоть и совсем не в такой экстремальной степени, с ошибками: вы видите ошибку, как результат сложного взаимодействия пользователя с продуктом. Но часто не видите исходных причин. Ошибка, как правило, обнаруживается в одном измерении: например, говорят о конкретном элементе. Скажем, эффективность элемента управления, какое-то свойство. Действие в ряду других действий.

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

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

* * *

И еще одно элементарное логическое высказывание: в дизайне работа над ошибками является дизайном, но дизайн не является работой над ошибками.

Дизайн не является работой над ошибками.

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

Ctrl + ↓ Ранее