Никто не хочет учиться играть на XYZ.

Jan 10, 2015 22:21

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

Leave a comment

protivoyadie January 11 2015, 00:45:47 UTC
>LFM (languages designed for masses), навроде C++
Напомнило картинку))


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

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

> "Усилить" -- это быстрее по времени и лучше по качеству
В расчет того, что "быстрее", надо только время обучения еще не забывать включать. Ну т.е. в пределе "сложность скрипки" "окупается", если сэкономленное время при "игре на ней" в течение жизни превосходит время обучения (а ведь далеко не факт, что навык игры на скрипке будет использоваться все время жизни после его изучения! Голофоны то уже на подходе!).
В частности поэтому цепочка "творцов-программистов-кодеров-быдлокодеров-операторов-быдлооператоров-роботов" такая длинная - во всех автоматизациях есть оптимум сэкономленных автоматизацией ресурсов (в т.ч. временных!) vs затрат на автоматизацию. "Умная кофеварка", о которой говорит Atul Varma, наверное, не так часто ломается, чтобы каждому пользователю ежедневно пригождалось бы умение "играть на ней" (а если так, то надо "что-то менять в консерватории", производящей кофеварки, например, быдлокодеров на кодеров/программистов/творцов - смотря где оптимум!).

>Люди не любят "учиться играть на XYZ"
А и не надо заставлять людей любить тратить время на изучение технологии, которая обязательно вскоре сменится другой, на изучение которой снова надо будет тратить много часов.
Надо из умения "играть на XYZ" вычленять базовые навыки, лежащие в основе этого умения, и разрабатывать методики построения нужных "рельс мышления" у детей, мозг которых способен научиться "играть на XYZ" гораздо быстрее. Ну или думать, как увеличить продолжительность жизни, чтобы не так жалко было его тратить на "изучение игры на XYZ".
Короче, тут главное дотянуть до технической сингулярности, чтобы цепочка замкнулась (робот=творец), тогда то заживем!

Reply

father_gorry January 11 2015, 12:24:43 UTC
Купер (а до него Круг) имели главной идею, что интерфейс должен помогать выполнять задачи.
Сложность тут побоку.
Смотрите: программист изначально ориентирован на более сложные задачи, потому и интерфейс рисует навороченный.
И всё, нет никакой глобальной бойни дураков с умными:)

Reply

protivoyadie January 11 2015, 14:28:51 UTC
Сложность тут - самоцелью оказывается, если программист изначально не ориентирован на задачи пользователя вообще.

В частности, Купер приводит пример, когда интерфейс на самом деле решает не одну задачу, а три или четыре, ну т.е. в одном и том же интерфейсе предполагается работа пользователей с разными пользовательскими ролями (их use cases практически не пересекаются).
В качестве решения предлагается создание отдельных интерфейсов для разных пользователей (на основе их ролей). Но даже внутри одной роли интерфейс может оказаться слишком сложным. Тогда предлагается создание отдельных интерфейсов для новичков (с наиболее часто используемыми функциями) и для экспертов (полный контроль).
В пределе получается "адаптивный интерфейс", который дает пользователю столько возможностей, сколько ему нужно в текущий момент.

С созданием собственных фреймворков вообще ровно это происходит.
Если проводить параллели с кофеварками, то должно быть что-то такое: пока она работает нормально - у нее одна кнопка, как только начинаются проблемы - появляются новые кнопки (по 1 на каждую функцию). А вот с аккордовой клавиатурой такой фокус не прокатит - каждая новая кнопка - это сразу в 2 раза больше аккордов-функций.
Если проводить параллели со стандартами, то он тоже может быть представлен (разбит на части?) в такой форме - "недостандарт-стандарт без мелочей-полный стандарт", тогда и маркетологам будет проще честно указывать, а какой именно уровень матрешки этого стандарта они поддерживают своим софтом.

Reply


Leave a comment

Up