Алгебра интерфейсов

[vitus_wagner]

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

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

Все мы помним что случилось в области базостроения потом - пришли Кодд и Дейт и создали реляционную алгебру.
Сразу стало значительно понятнее, несмотря на то, что распространение полноценных, разработанных на основе этой теории языков QBE и SQL заняло десятилетия. И до сих пор достаточно популярны всякие mySQL-и, которые в полном объеме этого не умеют. Но во всяком случае, в мозгах у разработчиков некоторое прояснение наступило.

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

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

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

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

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

Comments

[roman_sharp.livejournal.com]

Статья по теме:
Between a rock and an interface (http://news.bbc.co.uk/2/hi/technology/7656843.stm)

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

[vitus_wagner]

Нужен-то ОДИН гений.

[metaclass.livejournal.com]

А еще отсутствие теории пользовательских интерфейсов не позволяет сделать нормально средства их автоматической генерации - обязательно получается скрещение ежа с ужом и постоянная необходимость результат допиливать вручную.

Хотя я почти уверен, что даже при наличии теории, пользователи сумеют придумать и потребовать что-нибудь, не вмещающееся в рамки теории. Вот, к примеру: как в теории описать требование пользователей "у программы не должно быть больших отступов от края окна до главного элемента управления". Разница - буквально в 5-10 пикселей при размере окна где-то 400х160 пикселей, на функциональность не влияет вообще, но есть требование - его надо выполнять.

[abbra]

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

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

[http://users.livejournal.com/_winnie/]

GUI - это будет совершенно отдельная теория. На автомате генерирующийся GUI из интерфейса - он не может быть удобным.

[dimrub.livejournal.com]

А что именно MySQL из SQL не имплементирует? Мне казалось, он полностью всю спецификацию умеет.

[vitus_wagner]

Там на наиболее распространенном типе таблиц referential integrity по-моему до сих пор не работает.

[blacklion.livejournal.com]

SQL как бы сам по себе не полностью описывает реляционную алгебру ;-)

[plumqqz.livejournal.com]

WITH

[ylevdik.livejournal.com]

Могу попытаться ответить на вопрос об эквивалентных классах интерфейсов:

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

- визард удобен в качестве пошагового создавателя (или установщика) некоего объекта (возможно, по шаблону), который потом может иметь и таблицу контролов в том числе.

Поэтому я не стал бы именно эту пару называть эквивалентной - напротив, tabbed dialog и wizard как раз НЕэквивалентные GUI - именно в силу задач, для решения которых они предназначены.

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

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

[vitus_wagner]

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

А вот диалог который живет на фоне какого-то выполняющегося процесса и отражает текущее состояние - это даже пример такой программы сходу в голову не приходит.

[plumqqz.livejournal.com]

Вот уж CODASYL/сетевая модель куда как естественней и проще реляционной. Другое дело, что реляционная модель тупо эффективней.

[fdo-eq.livejournal.com]

Эффективней - это тоже смотря еще на каких задачах...

[vitus_wagner]

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

[blacklion.livejournal.com]

Про интерфейсы, ООП и реляционную алгебру именно в таком контексте еще Луговской писал :)

[nasse.livejournal.com]

Мне что-то подсказывает, что все элементы, из которых состоит современный интерфейс, плохие. Включая кнопку "Пыщь"

[beskov.livejournal.com]

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

Клёво. А у игр интерфейсы есть? Они по тем же законам существуют? А промо-сайты?

Если говорить о теории GUI, то может стоит говорить и о теории упаковки?

[eldhenn]

>А у игр интерфейсы есть?

Есть. Бывает, сядешь за игру, и всё понятно - что и как делать. Например, игры от Blizzard. А бывает, запустишь - и полчаса в кнопочки тыкаешься, пытаясь понять, как ЭТИМ ВСЕМ управлять можно.

[lupus-lupusum.livejournal.com]

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

[vitus_wagner]

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

[beldmit.livejournal.com]

Витус, я не согласен с тем, что теория должна быть математической.

[vitus_wagner]

Это ты просто их готовить не умеешь. В смысле математические теории. Но бывают люди, которые их готовить умеют.
С нематематическими теориями - хуже. Их никто толком готовить не умеет.

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

[guamoka.livejournal.com]

Вообще, было бы интересно посмотреть хотя бы на 3-ю нормальную форму интерфейса:) И вообще, что есть корректный с мат. т.з. интерфейс, а что- некорректный для текущего набора данных/user requirements? Или как формализовать правило, почему вот в таком-то случае необходимо использовать TreeControl, а в этом ListControl? Не говоря уже про "нестандартные" визуальные элементы.

[guamoka.livejournal.com]

Кстати, уж лучше попробовать Фен Шуй...

сообщество, близкое по теме

[dinus.livejournal.com]

Может быть, что нибудь интересное найдете здесь? http://community.livejournal.com/ru_ucdesign/profile Это сообщество как раз по поводу интерфейсов, но "с другой стороны".

[copylove.livejournal.com]

Создать теорию пользовательского интерфейса в настоящий момент это утопия (и скорее всего будет утопией в обозримом будущем). Вот только часть аргументов за эту точку зрения:

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

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

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

4. Интерфейс должен быть пластичным, то есть позволять изменять себя на протяжении своего жизненного цикла. Как это формализовать?

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

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

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

8. Сейчас на западе самая горячая тема это green и sustainability -- то есть вопросы экономного расходования ресурсов, то есть экологичности продуктов, которые мы создаем. С помощью интерфейса можно добиться того, что будет осуществляться экономия ресурсов -- например бортовой компьютер в некоторых автомобилях показывает, что водитель ведет машину в максимально экономном режиме (с меньшим выбросом загрязнений). Давайте попробуем это формализовать подобные аспекты интерфейсов :)

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

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

[picwork.livejournal.com]

Соглашусь со всем. )

Вы главного не понимаете.

[picwork.livejournal.com]

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

Да и собственно такая алгоритмизация и есть частный случай проектирования ПИ.

можно брать готовые разработки интерфейсов

[lupus-lupusum.livejournal.com]

не обязательно алгоритмизировать, можно попробовать реюзить ранее разработанное

[a-sure.livejournal.com]

Преамбула:
"3я нормальная форма возникла из-за того, что данных было много, а диски стоили ужасно дорого. Сейчас ситуация иная, и при проектировании системы класса BI мы вынуждены создавать избыточность в данных, чтобы выиграть в производительности" волльный перевод Donald Burleson.


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

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

Т.е. объективных условий - платежеспособный спрос - я со своей кочки не вижу.
Только если какой-то гений.

[plumqqz.livejournal.com]

""3я нормальная форма возникла из-за того, что данных было много, а диски стоили ужасно дорого. Сейчас ситуация иная, и при проектировании системы класса BI мы вынуждены создавать избыточность в данных, чтобы выиграть в производительности" волльный перевод Donald Burleson."

Вы, пардон, фотографию этого Бурлесона видели? Вопросы есть?

[os80.livejournal.com]

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

[vitus_wagner]

Собственно, в первую очередь именно это я и имею в виду. Соответствие функциональности интерфейса решаемой задаче. Онтология - это вообще из области формальной логики. Чисто математическая дисциплина.

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

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