Алгебра интерфейсов
Nov. 25th, 2008 02:19 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerСовременное состояние дел в области проектирования и реализации интерфейсов пользователя чем-то напоминает
ситукцию с созданием баз данных во времена CODASYL
Куча всяческих эвристик, куча guidelines, использование избыточно мощных парадигм (OOP).
Даже работы Раскина - это не более чем набор эвристик, применимых в довольно частном случае.
Как результат - интерфейсы получаются громоздки, неудобные, тормозные, ресурсоемкие.
Все мы помним что случилось в области базостроения потом - пришли Кодд и Дейт и создали реляционную алгебру.
Сразу стало значительно понятнее, несмотря на то, что распространение полноценных, разработанных на основе этой теории языков QBE и SQL заняло десятилетия. И до сих пор достаточно популярны всякие mySQL-и, которые в полном объеме этого не умеют. Но во всяком случае, в мозгах у разработчиков некоторое прояснение наступило.
На мой взгляд, IT в наше время остро нуждается в создании математической теории интерфейса пользователя.
Понятно, что раз тут есть такое плохо формализуемое существо, как человек, задача создания этой теории крайне непроста. Но программа-то, которая с человеком взаимодействует через этот интерфейс - объект до конца формальный.
Сейчас разработка интерфейсов напоминает скорее художественный дизайн, чем проектирование технической системы.
Но ведь на самом деле интерфейс - штука до предела функциональная. Главное в нем не рюшечки, а наглядное представление необходимой для принятия решения информации, и получение от человека возможно более однозначного (и с наименьшей вероятностью ошибки) результата принятия этого решения.
Опять же следует учесть, что рассматривать надо не принятие единичного решения, а типичный путь по "развилкам", проходимый пользователем в процессе решения задачи.
Очевидно, что существуют какие-то классы эквивалентности интерфейсов. Например обычное диалоговое окно с кучей контролов, tabbed dialog и wizard могут предоставлять ровно ту же самую информацию и позволять те же самые варианты принятия решений.
А вот в каких случаях удобнее то представление, а в каких - другое - никаких правил пока нет. Можно сравнить эту ситуацию, скажем с с нормальными формами в РСУБД. Там во всех учебниках написано, когда надо делать нормализацию, а когда - денормальизацию. Хотя в любой конкретной ситуации решение все равно остается за проектировщиком, но он хотя бы знает к чему приведет то или другое решение.
ситукцию с созданием баз данных во времена CODASYL
Куча всяческих эвристик, куча guidelines, использование избыточно мощных парадигм (OOP).
Даже работы Раскина - это не более чем набор эвристик, применимых в довольно частном случае.
Как результат - интерфейсы получаются громоздки, неудобные, тормозные, ресурсоемкие.
Все мы помним что случилось в области базостроения потом - пришли Кодд и Дейт и создали реляционную алгебру.
Сразу стало значительно понятнее, несмотря на то, что распространение полноценных, разработанных на основе этой теории языков QBE и SQL заняло десятилетия. И до сих пор достаточно популярны всякие mySQL-и, которые в полном объеме этого не умеют. Но во всяком случае, в мозгах у разработчиков некоторое прояснение наступило.
На мой взгляд, IT в наше время остро нуждается в создании математической теории интерфейса пользователя.
Понятно, что раз тут есть такое плохо формализуемое существо, как человек, задача создания этой теории крайне непроста. Но программа-то, которая с человеком взаимодействует через этот интерфейс - объект до конца формальный.
Сейчас разработка интерфейсов напоминает скорее художественный дизайн, чем проектирование технической системы.
Но ведь на самом деле интерфейс - штука до предела функциональная. Главное в нем не рюшечки, а наглядное представление необходимой для принятия решения информации, и получение от человека возможно более однозначного (и с наименьшей вероятностью ошибки) результата принятия этого решения.
Опять же следует учесть, что рассматривать надо не принятие единичного решения, а типичный путь по "развилкам", проходимый пользователем в процессе решения задачи.
Очевидно, что существуют какие-то классы эквивалентности интерфейсов. Например обычное диалоговое окно с кучей контролов, tabbed dialog и wizard могут предоставлять ровно ту же самую информацию и позволять те же самые варианты принятия решений.
А вот в каких случаях удобнее то представление, а в каких - другое - никаких правил пока нет. Можно сравнить эту ситуацию, скажем с с нормальными формами в РСУБД. Там во всех учебниках написано, когда надо делать нормализацию, а когда - денормальизацию. Хотя в любой конкретной ситуации решение все равно остается за проектировщиком, но он хотя бы знает к чему приведет то или другое решение.
