вторник, 24 мая 2011 г.

Описание настраиваемого пользователем интерфейса (ICI, Individual Customizable Interface)


Введение

            В мире создано множество вариантов пользовательского интерфейса для компьютерных программ.  Имеются в виду экранные интерфейсы с управлением разнообразными клавиатурами, компьютерными мышами, джойстиками, тачскринами и другими устройствами ввода.
            В данном случае речь идёт о настраиваемом пользователем пользовательском интерфейсе ICI (Individual Customizable Interface) . Конечно, что бы пользователь смог сам настроить интерфейс под себя, он должен иметь определённую квалификацию. Но в наше время в спецификации этого интерфейса разберётся почти любой школьник.
            Устройства с экранами меньше 640 на 480 пикселей наверно уже мало кого интересуют, как компьютер. Соответственно, если к устройству с экраном 640 на 480 и более невозможно ни как прицепить USB клавиатуру, то такое изделие тоже мало кого заинтересует как компьютер.
Идея настраиваемого интерфейса состоит в следующем. Так же, как изготавливаются панели управления в промышленности, путём набора из стандартных элементов интерфейса (в дальнейшем ЭИ) типа лампочек, кнопок, переключателей, табло, экранов и звуковых устройств типа микрофона, сирены или динамика, так и пользователь сможет собрать любой интерфейс для своих нужд из стандартных элементов.
Отличие от обычного интерфейса WIMP состоит в том, что после настройки интерфейса его достаточно перезапустить, а перекомпиляция не нужна. Это возможно потому, что элементы интерфейса и его настройки записаны в файле. Файл имеет открытый стандарт, это просто текстовый файл.
Кроме того, при переносе на другую платформу текстовый файл описания интерфейса не изменяется, используется только другой исполняемый файл интерфейса. Текстовый файл описания интерфейса можно сравнить с понятием Skin (кожа, шкура) для программ. Например, библиотека Qt имеет (в 2010 г.) всего три шкуры: Plastik, Keramik, and Windows. Однако в данном случае  предлагается открытый стандарт, что позволит любому пользователю сделать так, как ему удобно. Кроме того, обычные реализации Skin позволяют только добавлять элементы управления (controls), но не изменять их работу, их алгоритм, их отображение.
Исполняемый файл интерфейса ICI – собственно ICI-программа, осуществляющая интерфейс на конкретной платформе, нечто, похожее на java-машину. При старте или перезапуске ICI-программа читает файл с настройками интерфейса и дальше осуществляет интерфейс, описанный в файле.
            На конкретном компьютере интерфейс имеет вид исполняемого файла. Если используется Windows, то это исполняемый exe-файл.

Входы и выходы интерфейса

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

Со стороны компьютера

            Сначала рассмотрим входы и выходы со стороны компьютера.  Под стороной компьютера имеется в виду любая пользовательская программа, поддерживающая описываемый стандарт, вместо привычного всем оконного интерфейса. Под поддержкой стандарта понимается возможность передачи данных между ICI-программой и пользовательской программой.
            Допустим, для передачи данных между этими программами используется протокол TCP/IP. Тогда ICI-программа и пользовательская программа могут находиться на одном компьютере или на разных компьютерах. Кроме того, возможны варианты, когда одна пользовательская программа обменивается данными с неизвестным заранее количеством (например, десятки тысяч) ICI-программ. В данном случае ICI-программа играет роль, похожую на браузер, а пользовательская программа – что-то вроде web-сервера. Возможен и обратный вариант, когда одна ICI-программа связывается с сотнями пользовательских программ, то есть подобно закладкам в браузерах.
            Инициатором создания канала связи  (например, TCP-соединения) может быть только ICI-программа. Инициатором передачи данных могут быть обе программы: и ICI-программа, и пользовательская программа.
            Какие же данные получает ЭИ от программы пользователя и передаёт программе пользователя? Только такие, которые «понимает» ЭИ, в следующих сообщения будет описание атрибутов ЭИ.

Со стороны пользователя

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

Вывод пользователю

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

Атрибуты ЭИ
1)     Координаты X, Y, Z (X, Y – в пикселях, Z – в слоях);
2)     Скорости Ux, Uy, Uz (Ux, Uy – в пиксели на кадр, Uz – слоёв на кадр);
3)     Координаты центра вращения в плоскости экрана X, Y;
4)     Начальный угол D в плоскости экрана в радианах;
5)     Угловая скорость W в плоскости экрана в радианах на кадр;
6)     Масштабы по осям Sx и Sy в долях от 1 до 0;
7)     Изменение интенсивности каждого цвета RGB на указанный от 0 до 255;
8)     Прозрачность в долях от 1 до 0.
9)     Состояние ЭИ, целое положительное число.

Очевидно, что обобщить эти данные элемента интерфейса на 3D экраны и реализовать, например на Win API, Open GL, или Qt, особого труда не составит.

Ввод пользователя

            Ограничимся следующим набором событий, которые могут поступать ICI-программе от пользователя. Как они реализованы на различных платформах, предмет отдельного разговора. Но в целях стандартизации ограничимся следующими событиями.
           
Первый список
1)     Нажали (вариант - отпустили) клавишу на клавиатуре;
2)     Нажали на экран указателем N в точке (X,Y);
3)     Указатель N убрали с экрана.
Указателей может быть несколько. Кажется, не составит особого труда написать программу, которая, используя два типа событий  «Нажали на экран указателем N в точке (X,Y)» и «Указатель N убрали с экрана» создаст события, например такие:
Второй список
1)     «Сильно» нажали на кнопку указателем N;
2)     «Тащат» по экрану рисунок указателем N;
3)     Жест вращения рисунка;
4)     Жест уменьшения масштаба;
5)     Жест увеличения масштаба;
6)     Жест удаления;
7)     Клавиша Ctrl и «Жест уменьшения масштаба»;
и т.д. до бесконечности. Для описания событий во втором списке можно использовать комбинацию событий первого списка и описать в ICI-тексте.
События, генерируемые известными устройствами ввода, практически любые, сводятся либо к первому списку, либо к их комбинации, как во втором списке. Может быть, скоро появятся особые устройства ввода трёхмерной информации, тогда добавится координата Z.
Конечно, в общем случае, могут быть и другие события, например интерфейс распознавания жестов и гримас лицом (улыбки), или руками, даже съём мозговой активности пользователя. В этом случае всегда есть конечный список событий, которые выдаёт на выходе этот интерфейс, кроме того, некоторые события имеют привязку к координатам, уж так устроен этот мир. В этом случае соответственно расширяется первый, базовый список. Второй список и так всегда бесконечен.

пятница, 25 марта 2011 г.


Программа интерфейса человек-компьютер (HMI)

Когда-то, давным-давно читал книжку по MS Windows 3.1 и прочёл слова: «оконный интерфейс». Странно, подумалось мне. Ведь в жизни, как инженеру, приходилось в основном работать с документацией и приборами. Документация состоит из листов, приборы имеют обычно лицевую панель, а окна тут причём?

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

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

Геометрия и события

Геометрия и физика

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

Рисунки рисуются в плоскости экрана с координатами X и Y. Рисунки могут накладываться друг на друга и имеют третью координату Z. Два рисунка могут иметь одинаковую координату Z, но тогда они не могут накладываться. Все рисунки могут изменять цвет, размер, могут вращаться, двигаться в плоскости XY и по оси  Z, становится прозрачнее, вплоть до невидимости и снова появляться.

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

Интерфейс должен быть дружественным.

События и физика

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

Если лист лежит, ничем не закрепленный, можно пальцем передвинуть лист, приложив определенные усилия, но двумя пальцами, взяв за угол листа легко можно перенести с места на место, или вытащить лист из-под кипы бумаг.
Стол сдвинуть нельзя.
Вот вращения можно сделать так: одним пальцем прижать там, где нужен центр вращения, другим вращать.

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

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

Не должно быть неожиданных  появлений объектов после событий, типа всплывающих окон или меню. Если Вы коснулись экрана, этот факт должен быть подкреплён рисованием «отпечатков» Ваших пальцев на экране, желательно полупрозрачных. Если Вы убрали пальцы, «отпечатки» «растают».

Если Вы двигаете лист А с координатой Z = 2 и рядом лежит ещё лист В с такой же координатой, Вы не сможете сдвинуть лист А дальше, лист В мешает, сначала уберите лист В в сторону, или двигайте лист А по другой траектории.

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

Программирование

Зачем всё это

Когда учился в вузе, была военка,  и там приходилось выучивать наизусть фразы, например: «Кран для слива топлива находится в передней левой нижней части заднего правого топливного бака».

Просто надоело мучиться в различных программах из-за недостатков интерфейса, надоело читать толстенные книжки с описанием интерфейсов различных программ. Вот скажите, где, условно говоря, в «Фотошопе» устанавливается язык документа или в «Ворде» кегль шрифта и разрядка в строке?

Как сдвинуть в третьем столбце пятый абзац на два пиксела влево в каждой зелёной странице сайта про мобилки, если используется популярная CMS?
А это зависит, какой шаблон вёрстки, какой браузер, какой… и т.д. Сущность то одна, как в старых Page Maker и Ventura Publisher – вёрстка.

Надоело делать по-разному и разными инструментами программы для локального и веб интерфейса, ведь даже Майкрософт теперь Сильверлайтит.

Надоело работать в не универсальном интерфейсе, где из-за недогадливого разработчика теряется производительность труда.
Надоели макросы в стиле «Екселя» с абсолютной адресацией.

Пользователь-профессионал (да и просто пользователь) ДОЛЖЕН иметь возможность допилить интерфейс под свои текущие потребности и аппаратную платформу и создать групповую обработку, если нужно. Авторы программ просто не могут (или не хотят) предусмотреть все насущные потребности пользователей.

Как это сделать

Мир сделан из атомов, которых в таблице Менделеева меньше 300 штук. Для 99,99% программ обычно хватает с пару десятков стандартных элементов ввода-вывода информации с учётом вышеописанных возможностей. Каждый элемент имеет спецификацию входов-выходов.

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

Передача и приём информации от и к интерфейсу происходит, скажем, по TCP/IP, таким образом, веб- и локальная реализации интерфейса  теряют различия. Благодаря этому разные части программы необязательно работают на одном компьютере, а работающие на одном компьютере необязательно в одной программе или процессе или нитке, и не обязательно на одном процессоре. К тому же появляется возможность на лету переключать интерфейс к другому адресату.

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

Разве программисты хуже архитекторов или электриков?

Интерфейс в текстовой форме

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

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

Это же уже давно изобретено!

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

А вот HTML и CSS вроде бы открытые стандарты. Но позвольте заметить, HTML – язык ТЕКСТОВОЙ разметки. Его неоднозначность и чрезмерная усложнённость, как следствие сложность реализации приводит к ноченеспанию, красноглазию и паутинопрограммам. А про отличия IE и других браузеров между собой можно и не вспоминать.

В предлагаемой редакции чтение и интерпретация собственно текста интерфейса не вызывает сложности, получается около 500 строк на С++ или Java. Заметим, что место расположения файла текста с содержимым интерфейса неважно.

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

А как же программирование на стороне клиента?

Конечно, JS даёт гораздо большие возможности, но они не нужны. Нужно только то, что описано про «Геометрию и События» и ничего больше.

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

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

Закон сохранения говорит о том, что проблем с «чистильщиком памяти» нет, потому что он не нужен для интерфейса. При старте создаётся «вселенная» данного интерфейса, один раз выделяется память и всё.

Почувствуйте себя творцом.

Но мне нужен Арканоид!

А как же без программирования поведения предметов интерфейса?

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

Но для одного раза и так многовато.

Кому интересно, вопросы задавайте по hebrehebr@gmail.com
До свиданья.