Языки описания пользовательских интерфейсов


Содержание

Языки описания пользовательских интерфейсов

Язык описания интерфейсов

Язык описания интерфейсов (IDL), используемый OMG определяет типы объектов посредством спецификации их интерфейсов. Интерфейс состоит из множества именованных операций и их параметров. Хотя и описание на IDL обеспечивает ORB всей необходимой информацией о типе объекта, для работы вовсе необязательно, чтобы ORB-у был доступен исходный текст этих описаний. Эта же информация может быть заложена также в виде заглушек со стороны клиента и скелета со стороны сервера, а также в динамически изменяемом хранилище описаний, что позволит ORB-у нормально функционировать.

Язык описания интерфейсов рассматривается как средство, с помощью которого реализация объекта сообщает своим потенциальным клиентам о том, какие операции доступны и каким образом их следует вызывать. Можно оттранслировать описание на языке IDL в исходный код на конкретном языке программирования.

Отображение IDL в языки программирования

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

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

Типы данных

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

Объектным типом называется тип, членами которого являются объекты, удовлетворяющие данному типу.

Определены следующие основные (базовые) типы данных:

  • 16 и 32 разрядные знаковые и беззнаковые целые типы;
  • 32 и 64 разрядные типы с плавающей точкой в соответствии с IEEE;
  • символьный тип в соответствии с ISO Latin-1 (8859.1);
  • логический тип с множеством значений истина и ложь;
  • 8 разрядный тип, который гарантированно не подвергается никаким изменениям при передаче между различными системами;
  • перечислимые типы, состоящие из последовательности идентификаторов;
  • строковый тип, состоящий из последовательности символов переменной длины, длина строки доступна во время выполнения программы;
  • тип «any», который может принимать значения всех базовых и составных типов.

Также могут быть определены составные типы:

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

Синтаксис Общего Представления Данных — CDR

CDR — это способ представления всех типов данных, определенных в OMG IDL в виде последовательности восьмиразрядных величин, далее называемых байтами.

Поток байт представляет из себя некоторую абстракцию обычно соответствующую буферу данных, который передается между процессами или машинами с помощью средств IPC или сетевого транспорта. Далее считается, что поток байт или просто поток — это последовательность переменной (но конечной) длины величин, состоящих из 8 бит (байт) с четко определенным заголовком. Байты в потоке нумеруются от 0 до n-1, где n — это длина потока. Индекс каждого байта используется для вычисления границ выравнивания, как это описано далее.

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

Кодирование базовых типов

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

Для того, чтобы сделать возможным помещение и извлечение значений базовых типов в поток и из потока с помощью подпрограмм, предназначенных для работы именно с этими типами данных, все базовые типы данных при помещении в поток должны быть выровнены на свою естественную границу, то есть на число байт, которое нацело делится на число байт, необходимых для представления этого типа. Таким образом значение, имеющее размер n должно кодироваться с позиции m*n, где m — это целое число. В CDR n может принимать значения 1, 2, 4 или 8. Если необходимо, то выровненному значению предшествует область минимально возможного размера, необходимого для выравнивания. Значение байтов внутри этой области не определено.

Выравнивание определяется относительно начала потока. Первый байт в сообщении или инкапсуляции имеет индекс 0.

Кодирование составных типов

Выравнивание составных типов не налагает никаких дополнительных требований, кроме тех, которые применяются при кодировании их элементов.

Элементы структуры кодируются в том порядке, в котором они определены в описании на IDL. Каждый элемент кодируется образом, соответствующим его типу.

Объединение кодируется значением дискриминатора и членом объединения, соответствующим данному значению.

Массив кодируется как последовательность его элементов. Так как длина массива фиксирована, она не кодируется. Если массив имеет несколько измерений, то первый индекс изменяется наиболее медленно, а последний — наиболее быстро.

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

Строка кодируется как величина типа unsigned long, содержащее длину строки, и отдельными символами — элементами строки. Длина строки и ее представление в виде списка символов включают завершающий нулевой символ, что дает возможность использования стандартных функций библиотеки языка C (например, strcpy) для декодирования сообщения.

Значение перечислимого типа кодируется в виде величины типа unsigned long, соответствующей данному значению. Первому в порядке перечисления в определении на IDL значению соответствует 0, второму — 1 и так далее.

Кодирование инкапсуляции

Первый байт инкапсуляции кодирует порядок байт внутри нее — значение типа 0 означает кодирования по принципу первым — старший байт, 1 — младший. Далее идут данные. Флаг порядка байт не включается в данные, но он включается в инкапсуляцию. Все значения внутри инкапсуляции выравниваются относительно ее начала, первый байт (с индексом 0) соответственно занимает флаг порядка байт. Если инкапсуляция кодируется как последовательность величин типа octet (байтов), то ей предшествует значение типа unsigned long, содержащее общий размер инкапсуляции. Никакого выравнивания для инкапсуляции не предполагается, но такой способ кодирования всегда гарантирует 4-байтное выравнивание для первого байта инкапсуляции.

Кодирование псевдообъектов

Спецификация CORBA определяет несколько псевдообъектов, которые не являются ни базовыми ни составными типами и кодируются специальным образом. Ввиду особой специфичности данного кодирования и оно здесь не рассматривается.

Операции

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

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

Хранилище описаний

Хранилище описаний представляет из себя сервис, который обеспечивается постоянным объектом, доступном из программы. Во время выполнения программы он дает доступ к информации, аналогичной той, что сохраняется в IDL описании объекта. Эта информация может быть использована для выполнения запроса — таким образом программа, которая не предусматривала использование объекта какого-либо типа, определить доступные у этого типа методы, типы его параметров и осуществить вызов.

Список языков описания пользовательских интерфейсов

Список языков описания пользовательских интерфейсов

Содержание

Flash

  • CookSwing [1]
  • FXML [2]
  • SwiXML [3]
  • SwixNG [4]
  • Thinlet [5]
  • Ultr >Microsoft

Nokia

Mozilla

Другие

  • Curl — также язык программирования
  • HTMLR
  • UIML
  • PSML
  • Gul
  • XWT
  • QuiX
  • XML Sapiens
  • Bindows
  • Boxely(Website)
  • VTML
  • XHPD
  • XAL
  • MyXaml [9]
  • XRC — используется в wxWidgets
  • libavg
  • GNUstep Renaissance

UIML — пионер в языках разметки пользовательского интерфейса. Это открытый стандарт, реализации которого не ограничены единственным производителем. Однако, он не привлек большого внимания.

XUL — основной язык интерфейсов программ Mozilla Foundation. Документы XUL создаются движком Gecko, который также визуализирует документы XHTML и SVG. Он взаимодействует со многими существующими стандартами и технологиями, включая CSS, JavaScript, DTD и RDF, которые делают его относительно простым для изучения людьми с поверхностными знаниями веб-программирования и дизайна.

Расширяемый язык приложений (англ. eXtensible Application Language ) — язык разметки из Nexaweb’s Enterprise Web 2.0 Suite. Разработчики могут использовать этот язык для описания приложений, которые будут запускаться как клиент Java или AJAX.

Scalable Vector Graphics — язык разметки для графики, предложенный W3C, который может поддерживать графику с широкими возможностями для веб-приложений и мобильных приложений. Несмотря на то, что SVG не является языком описания пользовательского интерфейса, он включает поддержку векторной/растровой графики, анимации, взаимодействия с DOM и CSS, встроенного media, событий и скриптов. При комбинировании этих возможностей возможно создание интерфейсов пользователя с широкими возможностями.

XAML — система разметки, которая лежит в основе компонентов пользовательского интерфейса Microsoft .NET framework 3.0 и выше. Его область применения более амбициозная, чем у большинства языков разметки пользовательского интерфейса, так как в XAML документ также включены программная логика и стили. Функционально, его можно рассматривать как комбинацию XUL, SVG, CSS и JavaScript в одной схеме XML.

I3ML — собственнический механизм доставки приложений с тонким клиентом, разработанный CoKinetic Systems Corp, с поддержкой клиента, обеспечиваемой плагином браузера, который отображает Windows-подобные приложения через инфраструктуру HTTP с минимальной необходимой полосой пропускания.

OpenLaszlo (LZX)

OpenLaszlo — платформа для разработки и доставки RIA приложений, включающая среду исполнения и язык описания интерфейса (Laszlo XML — LZX). LZX — декларативный язык описания пользовательского интерфейса, определяющий виджеты, компоновку приложений и скриптовые элементы (используя JavaScript) для создания приложений.

HMVCUL


Hierarchical Model View Controller User Interface Language (HMVCUL) — язык описания пользовательского интерфейса, основанный на XML, который поддерживает создание и связывание элементарных компонентов MVC триады, используемых в создании HMVC GUI приложений. Связанная среда исполнения предоставляет методы, которые делают возможной настройку свойств, привязки данных и событий каждого из элементов MVC триады (модель, виджет, контроллер). Среда исполнения достигает этого отображением XML элементов, определенных в HMVCUL файле, в объекты внутри фреймворка, а атрибутов — в свойства или события. Связывание достигается отслеживанием древовидной структуры, описанной в HMVCUL файле.

WasabiXML

WasabiXML — язык разметки, основанный на XML, используемый для определения графического интерфейса в приложениях Wasabi. Это очень часто используется в Winamp для создания скинов (skins). WasabiXML разработан Nullsoft для Winamp, но также может быть использован и с другими приложениями с Wasabi SDK.

Корневой элемент в WasabiXML (для скинов Winamp, это также ). Элемент показывает информацию о скине. Графический интерфейс содержится в элементе и базовый видимый элемент GUI — . Пример простого GUI с элементом кнопка (button):

WasabiXML поддерживает многие элементы GUI, включая:

WasabiXML имеет пространство имен XML ‘Wasabi::’, которое определяет основные GUI без необходимости описывать пути их изображений.

Другие

Другие языки разметки, встроенные в существующие фреймворки:

  • GladeXML — язык разметки для создания графических интерфейсов на основе GTK+
  • VTML для Macromedia HomeSite

Некоторые из них скомпилированы в бинарные формы.

В авионике стандарты ARINC 661 предписывают бинарный формат для описания пользовательских интерфейсов в стеклянных кабинах пилота.

Лекция № 14. Особенности разработки пользовательских интерфейсов

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

Цель лекции: ознакомиться с основными требованиями к разработке интерфейсов с учетом психофизических особенностей человека.

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

Информация о внешнем мире поступает в мозг в огромных количе­ствах. Часть мозга («процессор восприя­тия») постоянно без участия сознания перерабатывает ее, сравнивает с про­шлым опытом, и помещает в хранилище уже в виде зрительных, звуковых и прочих образов. Любые внезапные или просто значимые для нас изменения в окружении привлекают внимание, и тогда интересующая инфор­мация поступает в кратковременную память. Если же внимание не бы­ло привлечено, то информация в хранилище пропадает, замещаясь следую­щими порциями. В каждый момент времени фокус внимания фиксируется в одной точке. При необходимости одновременно отслеживать несколько ситуаций фокус перемещается с одного элемента на другой. При этом внимание «рассредоточивает­ся», и какие-то детали могут быть упущены. Так, при «прокрутке» тек­ста или рисунка с использованием линейки прокрутки окна Windows прихо­дится одновременно смотреть на текст и на ползунок. Поскольку текст важнее, фокус внимания перестает переме­щаться на мышь, и она «соскакивает» с ползунка линейки. Следует иметь в виду, что обработка процессором восприятия требует некоторого времени и, если сигнал выдается в течение времени, меньшем времени обработки, то наш мозг его не воспринимает. Восприятие во многом основано на мотивации. Например, если человек голоден, то он в первую очередь будет замечать все съедобное, а если устал — то, войдя в комнату, он в первую очередь увидит диван. Следует учитывать, что при переработке информации мозг сравнивает поступающие данные с предыдущими. Так, если показать человеку последовательность символов «А, 13, С»,то он может принять «13» за «В». При смене кадра мозг на некоторое время блокируется: он «осваивает» новую картинку, выделяя наиболее существенные детали, поэтому не стоит резко менять картинку, если не­обходима быстрая реакция пользователя.

Краткосрочная память является своего рода оперативной памятью мозга, именно с ней работает процессор познания, но не востребованная ин­формация хранится в ней не более 30 секунд. Ее емкость приблизительно равна 7 ± 2 несвязанных объектов. Чтобы не забыть важ­ную информацию, мы обычно повторяем ее «про себя», «обновляя» информацию в краткосрочной памяти. Поэтому при проектировании интерфейсов следует иметь в виду, что большинству людей сложно, например, запомнить и ввести на другом экране число, содержащее более 5 цифр (7 — 2), или некоторое сочетание букв.

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

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

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

Человеку свойственно субъектив­ное восприятие времени. Считают, что внутреннее время связано со скоро­стью и количеством воспринимаемой и обрабатываемой информации. Заня­тый человек времени не замечает. Зато в состоянии ожидания время тянется бесконечно: в это время мозг оказывается в со­стоянии информационного вакуума. Доказано, что при ожидании более 1-2 секунд пользователь может отвлечься, «потерять мысль», что увеличивает усталость и неблагоприятно сказывается на результатах работы. Сократить время ожидания можно, заняв пользователя, но не отвлекая его от работы. Например, предоставить ему какую-либо информацию для обдумывания или выводить промежуточные результаты.

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

В итоге взаимодействие пользователя с интерфейсом оп­ределяется не только его физическими возможностями и особенностямипо восприятию информации, но и пользовательской моделью интерфейса. Существуют три модели пользовательского ин­терфейса: модель программиста, модель пользователя, программная мо­дель. Программист при разработке интерфейса исходит из того, управление какими операциями нужно реализовать в нем, и как это осуществить, не затрачивая существен­ных ресурсов компьютера, своих сил и времени. Его интересуют эффективность, функци­ональность, технологичность, внутренняя стройность и дру­гие не связанные с удобством пользователя характеристики ПО. Именно поэтому большинство интерфейсов существующих программ вызывают серьезные нарекания пользователей. С точки зрения здравого смысла хорошим считается интерфейс, при работе с которым пользователь получает именно то, что он ожидал. Представление пользователя о функциях интерфейса можно описать в виде пользовательской модели интерфейса — совокупности обобщенных представлений конкретного пользователя или группы пользователей о процессах, происходящих во время работы программ­ной системы. Модель базируется на особенностяхопыта конкретных пользователей, который характеризуется уровнем подготовки в предметной области разрабатываемого ПО, интуитивными моделями выполнения операций в этой об­ласти, уровнем подготовки в области владения компьютером, а также устоявшимися стереотипами работы с компьютером. Для ее построения необходимо изучить особенности опыта предполагаемых пользователей, для чего используют опросы, тесты и фиксируют на пленку последовательность вы­полнения операций в реальном процессе. Приведение в соответствие моделей пользователя и программиста, а также построение на их базе программной модели интерфейса (рисунок 14.1) за­дача не простая. Чем сложнее автоматизируемая предметная об­ласть, тем сложнее строить программную модель интерфей­са, учитывающую особенности модели программиста и пользовательской модели. С этой точки зрения наиболее перспектив­ны объектные интерфейсы, так как в их основе лежит отображение объектов предметной области, которыми оперируют пользователи. Основой для разработки интерфейса должны стать интуитивные модели выполнения операций в предметной области. Нежелание или невозможность следования интуитивным моделям приводит к созданию искусственных надуманных интерфей­сов, которые негативно воспринимаются пользователями.

Рисунок 14.1 — Процесс разработки пользовательского интерфейса

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

Основными критериями оценки интер­фейсов пользователем являются:

а) простота освоения и запоминания операций системы — оце­нивают время освоения и продолжительность сохранения информации в па­мяти;

б) скорость достижения результатов при использовании системы — опре­деляется количеством вводимых или выбираемых мышью команд и на­строек;

в) субъективная удовлетворенность при эксплуатации (удобство работы, утомляемость и т. д.).

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

Дополнительную информацию по теме можно получить в [1, 4, 14].

15 Лекция № 15. Компоненты пользовательских интерфейсов. Технология Drag&Drop

Содержание лекции: диалоговые средства связи пользователей с ПК; технология Drag&Drop; интеллектуальные элементы пользовательских интерфейсов.

Цель лекции: ознакомиться с компонентами пользовательских интерфейсов и технологиями, применяемыми при их создании.

Диалог — это процесс обмена информацией меж­ду пользователем и программной системой, осуществляемый через интерак­тивный терминал и по определенным правилам. Различают тип диалогаи его форму. Тип диалога определяет, кто из «собеседников» управ­ляет обменом информацией. Соответственно различают диалоги, управляемые программой и управляемые пользователем. Диалог, управляемый программой, предусматривает наличие жесткого, линейного или древовидного сценария диалога, заложенного в ПО. Его сопровождают большим количеством подсказок, уточняющих, какую информацию необходимо вводить на каждом шаге. Диалог, управляемый пользователем,подразумевает, что сценарий диа­лога зависит от пользователя, применяющего систему для выполнения операций, а система обеспечивает возможность реализации различных сценариев пользователя.

Диалог невозможен без понятного «собеседникам» языка, описание которого включает синтаксис (правила, определяющие допустимые конструкции языка или его форму) и семантику (пра­вила, определяющие смысл синтаксически корректных конструкций языка или его содержание). В зависимости от вида синтаксиса и семантики различают три формы диалога:фразовую,директивную и табличную.

Фразовая формапредполагает «общение» на естествен­ном языке или его подмножестве. Содержание диалога в данной форме со­ставляют повелительные, повествовательные и вопросительные предложе­ния, а также ответы на вопросы. Общение может осуществляться в свободном фор­мате, но возможна и фиксация отдельных фраз. Поскольку организовать диалог на естественном языке достаточно сложно, чаще всего используют диалоги, предполагающие односложные ответы. В этом случае программа содержит ограниченное описание синтак­сиса и семантики используемого ограниченно-естественного языка. Для интеллектуальных систем интерфейсы создаются на базе огра­ниченного подмножества предложенийестественного языка. Синтаксис и семантика языков диалога, реализу­емых в таких интерфейсах, достаточно сложны. При обработке фраз в этих случаях оперируют понятием словоформа. Таким образом, интерфейс, реализующий фразовую форму диалога, должен преобразовывать сообщения из естественно-языковой формы в фор­му внутреннего представления и обратно, выполнять анализ и синтез сооб­щений пользователя и системы, отслеживать и запоминать пройденную часть диалога. Недостаткамифразовой формы при использовании подмножества естественного языка являются: большие затраты ресурсов, отсутствие гарантии однозначной интерпретации формулировок, необходимость ввода длинных грамматически правильных фраз. Достоинствосостоит в относительно сво­бодном общении с системой.

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

Табличная формапредполагает, что пользователь выбирает ответ из вариантов, предложенных программой. Язык диалога для табличной формы имеет про­стейший синтаксис и однозначную семантику. Однако применение табличной формы возможно не всегда: ее мож­но использовать только, если ограничено множество возможных ответов на конкретный вопрос (менее 20). Достоинствамитабличной формы являются: наличие подсказки; сокращение количества ошибок ввода (пользователь не вводит инфор­мацию, а указывает на нее); сокращение времени обучения пользователя; возможность совмещения с другими формами; возможность настройки пользователем. Недостатки: необходимость наличия навыков навигации по экрану; использование сравнительно большой площади экрана для изображе­ния визуальных компонентов; интенсивное использование ресурсов компьютера, связанное с необхо­димостью постоянного обновления информации на экране.

Типы и формы диалога выбирают независимо друг от друга: любая форма применима для обоих типов диалогов (рисунок 15.1).

Рисунок 15.1 -Соответствие типов диалогов и его форм

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

Пользовательские интерфейсы большинства современных программ строятся по технологии WIMP[14]: W — Windows (окна), I — Icons (пиктограммы), М — Mouse (мышь), Р — Pop-up (всплывающие или выпадающие меню). Основными элементами графических интерфейсов являются: окна, пиктограммы, компоненты ввода-вывода и мышь, использу­емая в качестве указующего устройства и устройства прямого манипулирова­ния объектами на экране.

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

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

Прямое манипулирование изображением это возможность замены команды воздействия на некото­рый объект физическим действием в интерфейсе, осуществляемым с помо­щью мыши. При этом любая область экрана рассматривается как адресат, ко­торый может быть активизирован при подведении курсора и нажатии клави­ши мыши. По реакции на воздействие различают следующие типы адресатов: указание и выбор, буксировка и «резиновая нить» (перенос объекта или его границ), экранные кнопки и «скользящие» барьеры (выполнение дискретных или циклических действий).

Для предоставления поль­зователям дополнительной информации в графических интерфейсах применяются динамические визуальные сигналы (изменение изображения объекта на экране при выполнении действий).

В окнах приложе­ний могут размещаться специальные компоненты ввода-вывода информации. Интерфейс обычно включает несколько меню: основное или «ниспада­ющее» иерархическое меню, пиктографические меню (панели инструмен­тов) и контекстные меню — компоненты ввода-вывода, реализующие диалог с пользо­вателем в табличной форме. Кроме меню в интерфейсе используют и другие компоненты ввода-вы­вода, которые можно разделить на три группы в зависимости от формы реализуемого диалога: фразовую, табличную или смешанную. Ди­рективная форма диалога предполагает ввод комбинаций клавиш или перемещение пиктограмм, а потому не требует использования компо­нентов ввода-вывода.

Возможность прямого манипулирования, предусмотренная в WIMP-ин­терфейсах, позволяет разрабатывать для приложений объектно-ориентиро­ванные интерфейсы прямого манипулирования. Интерфейсы данного типа на внешнем уровне используют директивную форму диалога: ввод команды осуществляется при выполнении определен­ных действий с пиктограммой объекта мышью. Их основными элементами являются: метафоры, объекты, представления объектов и тех­нология Drag&Drop [1].

Технология Drag&Drop («перетащил и бросил») определяет основные принципы прямого манипулирования, опи­санные в руководстве по разработке пользовательских интерфейсов фирмы IBM (CUA — Common User Access):

а) результат перемещения объекта должен соответствовать ожиданиям;

б) пользователи не должны неожиданно терять информацию;

в) пользователь должен иметь возможность отменить дей­ствие.

Эта технология также определяет основные принципы визуализации операции прямого манипулирования:

а) исходное выделение — используется в качестве обратной связи пользо­вателю, чтобы сообщить ему, что объект захвачен;

Илон Маск рекомендует:  Коды символов ASCII таблицы, понятие, применение

б) визуализация перемещения — идентификация выпол­няемого действия;

в) целевое выделение — идентификация пункта назна­чения;

г) визуализация действия — используется для обозначения времени ожи­дания завершения операции (изменение формы курсора на «песочные часы»).

В последние годы появилось много новых перспективных элементов пользовательских интерфейсов, привносящих в них эле­менты искусственного интеллекта: Мастер, Советчик, Агент. Сделано множество попыток создания социализированного пользовательского интерфейса, в основе которого интерфейса лежит идея создания персонифицированного («имеющего личность») интерфейса. Однако в этой области существуют психологические проблемы. Например, «безобидный» Советчик Microsoft Office вызывает у многих пользователей резко отрицательную реакцию.

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

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

Программные агенты— этоэлемент ПО, которому пользователь может передать часть своих обязанностей, используемый для выполнения ру­тинной работы. Их основные функции: наблюде­ние, поиск и управление. Различают:

а) программы-агенты, настраиваемые на выполнение указанных задач;

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

Дополнительную информацию по теме можно получить в [1, 5, 14, 18].

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Для студента самое главное не сдать экзамен, а вовремя вспомнить про него. 10041 — | 7504 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Есть ли таксономия / язык для описания пользовательских интерфейсов?

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

Итак, мой главный вопрос: есть ли таксономия / язык для описания пользовательских интерфейсов? Я много искал по этому вопросу, но в конечном итоге с такими вещами, как XUL. Который не то, что я ищу. Я ищу структуру / язык / таксономию для описания пользовательского интерфейса (диалогов). Однако я не уверен в его существовании. Так как я нет, я также был бы рад любым (поисковым) терминам, которые стоит исследовать в этом случае.

Кроме того, я также ищу языки / таксономии, которые используются для обычных систем интерактивной справки. То, с чем я столкнулся, было: DocBook, DITA и MAML. Есть ли другие крупные игроки на этом «рынке»?

2 ответа

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

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

Что касается интерактивных справочных систем, то DocBook и DITA являются двумя основными стандартами для написания документации, о которой я слышал. Существуют также такие программы, как RoboHelp и Помощь & amp; Руководство , которое может создавать онлайн-документацию.

Что такое разработка пользовательского интерфейса и зачем её заказывать

Что такое UI

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

Интерфейс — общая граница между двумя функциональными объектами, требования к которой определяются стандартом; совокупность средств, методов и правил взаимодействия (управления, контроля ) между элементами системы (источник: wikipedia.org).

Это точное, но скучноватое определение.

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


В повседневной жизни мы постоянно сталкиваемся с интерфейсами. Это и сайты соцсетей, и элементы управления в салоне автомобиля, и пульт ДУ для телевизора, и голосовое управление умным домом, и панель кнопок в лифте.

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

Зачем нужен UI

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

Лифт удобен. Он позволяет добраться до верхних этажей с минимумом временных и физических затрат. Но какой от него был бы толк, если бы мы не могли легко его открыть, выбрать этаж и при необходимости остановиться раньше времени? Всё перечисленное осуществимо, но каким путём? Позволит ли рычажное управление сделать пассажиру необходимые действия или разумнее будет использовать кнопочное управление? Тут и появляется важный момент: какой интерфейс управления лифтом выбрать.

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

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

Разработка UI

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

Грань между UX (User Experience) и UI (User Interface) очень тонка, но если разобраться, то становится ясно, что UX помогает понять пользователя. В больше психологического аспекта, нежели технологического. UX изучает пользователя: как пользователь живёт, что он думает, как и что делает и что его окружает. Перед дизайнером ставится задача — помочь обычному человеку легко разобраться с вашим программным продуктом и получить при этом удовлетворение от работы с ним.

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

Это реальная проблема, которую должен решить дизайнер, и с этапами решения этой проблемы мы познакомимся немного ближе.

Концепция

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

Создание мокапа

Этот этап позволяет быстро понять видение клиента и внести уйму изменений до начала разработки интерфейса. Мы намечаем расположение кнопок, форм и других нужных элементов, а уже потом подбираем цветовую палитру, шрифты, изображения, преобразуя всё это в удобный и красивый макет. То есть начинаем с варфрейма (план расположения элементов на странице), а заканчиваем созданием из этого плана красивой картинки. В случае разработки приложений под Android и iOS труд дизайнера облегчается гайдлайнами — правилами оформления и расположения элементов интерфейса, регламентом UX/UI, который был создан непосредственно экспертами по дизайну из Google и Apple.

User Flow Diagram (карта экранов)

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

Утверждение структуры

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

Выбор стиля UI

Существует множество различных концепций, например: material design, metro, skeuomorphism При выборе стиля интерфейса следует учесть текущие тенденции в дизайне, адаптивность, время на разработку и внедрение дизайна, и много других не менее важных моментов.

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

Согласование стиля

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

Интерактивный прототип

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

Для более наглядной демонстрации работы приложения инвесторам и потенциальным пользователям можно заняться разработкой интерактивного прототипа. Хотя стоит отметить, что это не обязательный этап, так как мокап+user flow diagram вполне себе является прототипом, описывающим будущий продукт с точки зрения UX. Однако интерактивный прототип даст более полное представление и о возможностях приложения, и об объеме работ по их реализации.

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

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

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

Утверждение результата

Вот он, последний этап работы над UI. Здесь всё очень просто: клиент оценивает результат, даёт комментарии и предложения, а мы при необходимости вносим правки.

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

Вывод

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

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

В «Психбольнице» Алана Купера говорится, что излишняя экономия на UI в дальнейшем выливается в трату на техподдержку, исправление ошибок, обучение новых сотрудников. Красивая обёртка в виде современного дизайна не есть человечный интерфейс; ключом к этой человечности служит проектирование под реального пользователя.

Проектирование интерфейса пользователя уменьшает время проектирования и упрощает взаимодействие пользователя с продуктом. Хорошо разработанный UI = благодарный пользователь = счастливый вы.

Список языков описания пользовательских интерфейсов (Cgbcjr zpsrjd jgbcfybz gjkmpjdfntkmcrb[ bynthatqcjd)

Список языков описания пользовательских интерфейсов

Содержание

По производителю или платформе

Flash

Nokia

Mozilla

Другие

  • Curl — также язык программирования
  • HTMLR
  • UIML
  • PSML
  • Gul
  • XWT
  • QuiX
  • XML Sapiens
  • Bindows
  • Boxely(Website)
  • VTML
  • XHPD
  • XAL
  • MyXaml[9]
  • XRC — используется в wxW > По свойствам и применению

UIML — пионер в языках разметки пользовательского интерфейса. Это открытый стандарт, реализации которого не ограничены единственным производителем. Однако, он не привлек большого внимания.

XUL — основной язык интерфейсов программ Mozilla Foundation. Документы XUL создаются движком Gecko, который также визуализирует документы XHTML и SVG. Он взаимодействует со многими существующими стандартами и технологиями, включая CSS, JavaScript, DTD и RDF, которые делают его относительно простым для изучения людьми с поверхностными знаниями веб-программирования и дизайна.

Расширяемый язык приложений (Шаблон:lang-en) — язык разметки из Nexaweb’s Enterprise Web 2.0 Suite. Разработчики могут использовать этот язык для описания приложений, которые будут запускаться как клиент Java или AJAX.

Scalable Vector Graphics — язык разметки для графики, предложенный W3C, который может поддерживать графику с широкими возможностями для веб-приложений и мобильных приложений. Несмотря на то, что SVG не является языком описания пользовательского интерфейса, он включает поддержку векторной/растровой графики, анимации, взаимодействия с DOM и CSS, встроенного media, событий и скриптов. При комбинировании этих возможностей возможно создание интерфейсов пользователя с широкими возможностями.

XAML — система разметки, которая лежит в основе компонентов пользовательского интерфейса Microsoft .NET framework 3.0 и выше. Его область применения более амбициозная, чем у большинства языков разметки пользовательского интерфейса, так как в XAML документ также включены программная логика и стили. Функционально, его можно рассматривать как комбинацию XUL, SVG, CSS и JavaScript в одной схеме XML.

I3ML — собственнический механизм доставки приложений с тонким клиентом, разработанный CoKinetic Systems Corp, с поддержкой клиента, обеспечиваемой плагином браузера, который отображает Windows-подобные приложения через инфраструктуру HTTP с минимальной необходимой полосой пропускания.

OpenLaszlo (LZX)

OpenLaszlo — платформа для разработки и доставки RIA приложений, включающая среду исполнения и язык описания интерфейса (Laszlo XML — LZX). LZX — декларативный язык описания пользовательского интерфейса, определяющий виджеты, компоновку приложений и скриптовые элементы (используя JavaScript) для создания приложений.

HMVCUL

Hierarchical Model View Controller User Interface Language (HMVCUL) — язык описания пользовательского интерфейса, основанный на XML, который поддерживает создание и связывание элементарных компонентов MVC триады, используемых в создании HMVC GUI приложений. Связанная среда исполнения предоставляет методы, которые делают возможной настройку свойств, привязки данных и событий каждого из элементов MVC триады (модель, виджет, контроллер). Среда исполнения достигает этого отображением XML элементов, определенных в HMVCUL файле, в объекты внутри фреймворка, а атрибутов — в свойства или события. Связывание достигается отслеживанием древовидной структуры, описанной в HMVCUL файле.

WasabiXML

WasabiXML — язык разметки, основанный на XML, используемый для определения графического интерфейса в приложениях Wasabi. Это очень часто используется в Winamp для создания скинов (skins). WasabiXML разработан Nullsoft для Winamp, но также может быть использован и с другими приложениями с Wasabi SDK.

Корневой элемент в WasabiXML (для скинов Winamp, это также ). Элемент показывает информацию о скине. Графический интерфейс содержится в элементе и базовый видимый элемент GUI — . Пример простого GUI с элементом кнопка (button):

WasabiXML поддерживает многие элементы GUI, включая:

WasabiXML имеет пространство имен XML ‘Wasabi::’, которое определяет основные GUI без необходимости описывать пути их изображений.

Другие

Другие языки разметки, встроенные в существующие фреймворки:

  • GladeXML — язык разметки для создания графических интерфейсов на основе GTK+
  • VTML для Macromedia HomeSite

Некоторые из них скомпилированы в бинарные формы.

В авионике стандарты ARINC 661 предписывают бинарный формат для описания пользовательских интерфейсов в стеклянных кабинах пилота.


Примечания

  1. ↑ (См. также HTA, подобная технология, ранее продвигаемая Microsoft для использования главным образом с Internet Explorer.)

| unknown = Шаблон:main other | preview = Страница использует Шаблон:Примечания с неизвестным параметром «_VALUE_» | ignoreblank = y | 1 | colwidth | group | liststyle | refs >>

[[К:Википедия:Статьи без изображений (указано в Викиданных: P18)|Шаблон:wikidataСписок языков описания пользовательских интерфейсов]][[К:Википедия:Статьи без изображений (указано в Викиданных: P242)|Шаблон:wikidataСписок языков описания пользовательских интерфейсов]][[К:Википедия:Статьи без изображений (указано в Викиданных: P373)|Шаблон:wikidataСписок языков описания пользовательских интерфейсов]]

Язык интерфейса Описание — Interface description language

Описание языка интерфейса или язык описания интерфейсов ( IDL ), является язык спецификаций , используемый для описания компонента программного обеспечения в интерфейс прикладного программирования (API). IDLs описывают интерфейс в языково-независимый подход, позволяющий связи между программными компонентами , которые не разделяют один язык. Так , например, между теми , кто написан на C ++ и написанные на Java .

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

Программные системы , основанные на IDLs включают компании Sun ONC RPC , The Open Group ‘S Distributed Computing Environment , IBM ‘ S объектной модели системы , в Object Management Group «S CORBA (который реализует OMG IDL, в IDL , основанный на АКД / RPC) и распределения данных Сервис , Mozilla ‘s XPCOM , Facebook ‘ s бережливость и WSDL для Web — сервисов .

Введение в разработку с применением XUL — языка описания интерфейсов на основе XML (исходники)

Что такое XUL?

XUL (XML User Interface Language) — это декларативный язык описания интерфейсов на основе XML. XML предоставляет богатый выбор интерфейсных компонентов (виджетов), которые ускоряют процесс разработки. Кроме этого, XUL — кроссплатформенный язык, т.е. приложение можно разрабатывать под Linux а запускать — под Windows. XUL тесно связан с такими Web-технологиями, как JavaScript и каскадные таблицы стилей (CSS). Можно даже вставлять фрагменты HTML прямо в приложение на XUL. Ниже мы подробнее рассмотрим возможности XUL, и что делает его столь привлекательной платформой для разработки.

XUL — это детище Netscape и Mozilla Foundation. Netscape с самого начала задумывался как кроссплатформенный браузер. Для этого потребовалась технология разработки интерфейса, которая бы абстрагировалась от платформеннозависимых аспектов создания и размещения элементов управления. В свою очередь, при использовании подобных технологий необходимо реализовать обмен данными между платформеннонезависимыми элементами и низкоуровневыми процессами, такими как файловый ввод-вывод, передача по сети и т.д. Кроме того, платформеннонезависимые компоненты должны были поддерживать HTML и элементы интерфейса, использующиеся в Web. В итоге, появилась XPFE (cross-platform front end) — технология, в будущем использованная для разработки Netscape Communicator, а также смежных продуктов, таких как почтовый и чат-клиент.

Возможно, вам известна история взлета и падения компании Netscape. Проведенный в 1995 году IPO, фактически ознаменовал то, что сейчас называют взлетом дот-комов (dot-com boom). Но уже к 1998 году финансовое состояние компании было неважным, хотя были и значительные технологические достижения, главным из которых был проект Mozilla. Он начался с открытия кода Netscape Communicator 4.0, который к тому времени было трудно сопровождать и развивать. Но, кроме собственно ядра Communicator, Netscape также открыл исходный код к своему интерфейсному движку следующего поколения, позднее названному Gecko. Одной из ключевых возможностей Gecko была поддержка декларативного, основанного на XML, языка описания интерфейсов — XUL.

XUL — это проприетарный язык описания интерфейсов, разработанный для движка Gecko. Однако, благодаря тому, что XUL построен на основе таких стандартных технологий, как XML, JavaScript и CSS, область его применения выходит далеко за рамки браузеров, использующих Gecko.

XUL — это язык на основе XML, от которого он унаследовал простой для чтения и разбора синтаксис. Также XUL во многом похож на HTML, что упрощает работу с ним для Web-разработчиков, которые могут, например, свободно сочетать использование элементов XHTML и XUL-виджетов. XUL убедительно доказал, что XML является идеальной основой для языков описания интерфейсов. Это также подтверждается появлением таких аналогичных языков, как MXML (интерфейсный язык, использующийся в Adobe Flex) от Adobe и XAML (язык, использующийся в .NET 3.0 и Windows Presentation Foundation) от Microsoft.

Разумеется, декларативное программирование имеет свои ограничения, так что рано или поздно императивное программирование все равно понадобится. Конечно, можно было создать для этого собственный язык или же придумать некий синтаксис на основе XML, но в XUL просто поддерживается использование JavaScript. В наши дни JavaScript заработал себе плохую репутацию языка, который хоть и легок для изучения непрофессионалами, но полон расширений и фокусов, специфичных для конкретного браузера. Но в то же время, JavaScript — это достаточно мощный язык, являющийся основой многих Web-разработок. Достаточно сказать, что JavaScript — это неотъемлемая часть Ajax (Asynchronous JavaScript and XML). Кроме поддержки объектно-ориентированной модели программирования, которую многие программисты предпочитают процедурной, JavaScript также позволяет писать код в функциональном стиле. XUL использует JavaScript как основной язык для разработки настольных приложений. Кроме этого, XUL тесно связан с реализацией DOM в JavaScript, что неудивительно, т.к. XUL построен на основе XML.

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

При этом и JavaScript, и CSS имеют репутацию технологий, реализация которых зачастую зависит от конкретного браузера. В частности, в JavaScript программисты иногда вынуждены реализовывать одну и ту же функцию несколько раз, в зависимости от типа и версии браузера у конечного пользователя. Эта же проблема характерна и для CSS при использовании условных стилей. Если у вас достаточный опыт в Web-программировании, то, скорее всего, вам приходилось сталкиваться с подобными трудностями. В этом случае, вам точно понравится XUL. Почему? Очень просто: в XUL вам всегда придется иметь дело только с одним браузером, как если бы все использовали исключительно Firefox.

Тем из вас, кто уже знаком с XUL, возможно показалось, что я забыл о двух очень важных аспектах: XPCOM и XBL. Но не волнуйтесь, мы сейчас рассмотрим эти технологии, а чуть позже увидим их в деле. Упор будет сделан на использование XPCOM и XBL для улучшения функциональности разрабатываемых приложений. Начнем с XPCOM.

XPCOM, или кроссплатформенная компонентная модель (Cross Platform Component Model), напоминает CORBA и Microsoft COM. В XPCOM библиотеки описываются моделью IDL, схожей с интерфейсами в Java и C#, или с WSDL для описания Web-сервисов. Внешние приложения, написанные на разных языках, могут обращаться к библиотеке через специальный интерпретатор XPConnect. Например, практически все возможности Gecko доступны через XPCOM. Несмотря на то, что само ядро написано на С++, обращения к нему возможны из любых языков, для которых реализована поддержка XPCOM, например таких как: JavaScript, C++, Perl и Python. В частности, можно обращаться к сетевой библиотеке Gecko через JavaScript.

XPCOM позволяет использовать возможности множества библиотек. Это часть идеологии XUL: дать разработчикам все необходимые возможности и компоненты, позволив им таким образом сосредоточиться на создании конечного продукта. Для этой цели XUL предоставляет обширную библиотеку виджетов, а также способы изменения их функциональности путем использования XBL — языка привязки к XML (XML Binding Language). Используя XBL, можно описать желаемое поведение компонента, а затем «привязать» данное поведение к виджету. Каким же образом осуществляется данная привязка? Это одно из хитрых мест в XBL: привязка делается через селекторы CSS. Другими словами, селектор используется для выбора одного или нескольких виджетов, а затем через специальное свойство -moz-binding указывается URL файла XUL, описывающего поведение виджета.

С чисто технической точки зрения, XUL — это очень интересный каркас для разработки кроссплатформенных приложений. Он мог бы и остаться просто интересным техническим решением, если бы не одно но: Firefox. XUL появился на свет как результат рефакторинга Netscape в целях повышения модульности. По схожему сценарию начиналась и разработка браузера Mozilla Firefox.

Firefox изначально создавался как некий минималистичный браузер на основе Gecko, что оказалось возможным благодаря модульной структуре последнего. Результат оказался невероятно удачным. Процент пользователей, использующих Firefox, вырос до 15% к маю 2007, что составляет более 75 миллионов человек. Firefox был удостоен самых хвалебных отзывов в таких известных журналах, как Forbes и PC World.

Изначально успех Firefox во многом определялся быстрым рендерингом и надежной системой безопасности Gecko. Затем свою роль сыграла и система расширений, позволяющая любому разработчику легко добавлять свою функциональность поверх Firefox. Благодаря этому написание модулей расширений для Firefox приобрело широкую популярность — к моменту написания данной статьи, официальный список Mozilla насчитывал более 1800 расширений. Разумеется, многие модули не вошли в официальный перечень.

Ключевым моментом является легкость создания модулей расширений, предоставляющих пользователю широкие возможности. Модули можно разрабатывать с помощью XUL точно так же, как и интерфейс Firefox — с помощью такого мощного средства XUL, как оверлеи (overlays). Используя оверлеи, можно получить доступ к местоположению некого интерфейсного компонента и вставить на его место свой собственный. На Рисунке 1. показано окно Firefox с несколькими установленными расширениями.

Элементы, добавленные модулями расширения, отмечены красными овалами. Отметьте несколько дополнительных кнопок на панели управления (между кнопкой Home и панелью навигации), а также иконки на панели состояния внизу окна браузера. XUL сильно упрощает вставку своих компонентов UI, что является основой благополучной интеграции расширений в Firefox.

Благодаря Firefox, XUL используется миллионами пользователей. Но XUL — это нечто большее, чем просто технология создания расширений для Firefox. Например, еще один продукт в линейке Mozilla — это почтовый клиент Mozilla Thunderbird. Как и следовало ожидать, он тоже написан с использованием XUL и предоставляет библиотеку расширений с помощью оверлеев. Хоть он и не так популярен, как Firefox, но, тем не менее, число скачиваний перевалило за 50 миллионов, так что существует высокая вероятность, что ваш провайдер уже предоставляет инструкции по настройке Thunderbird в качестве IMAP или POP-клиента для вашего почтового ящика. Но XUL задумывался именно как каркас для разработки кроссплатформенных настольных приложений, и он не ограничевается только линейкой продуктов Mozilla. Просто продукты Mozilla построены на основе Gecko, который отображает не только HTML-страницы и почтовые сообщения, но и интерфейсы самих программ, таких как Firefox и Thunderbird. Но многие приложения не требуют рендеринга HTML, поэтому и не используют Gecko. Но как же в таком случае они могут использовать XUL?

Ключом к этой проблеме является XULRunner — среда исполнения XUL, продолжающая традиции Gecko в части модулярности. XULRunner может использоваться вне Gecko, так что достаточно просто включать его в код разрабатываемого приложения.

Недостатком использования XULRunner является необходимость его включения в поставку вашего приложения, т.к. это добавляет лишних 12 МБ. Это не страшно для медиа-проигрывателя, например Songbird, т.к. большинство плееров в наши дни занимают достаточно много места. Точно также это не проблема в случае программы для просмотра потокового видео, например Joost. Для видео программ так или иначе необходимо скоростное соединение с Интернет, так что 12 МБ скачаются очень быстро. Однако легко представить, что во многих случаях размер XULRunner будет не меньше, а то и больше размера самих приложений, что существенно снижает его привлекательность.

Но есть надежда, что в один прекрасный день больше не понадобится привязывать приложения к XULRunner, потому как можно будет воспользоваться Firefox 3.0, который построен фактически на его основе. Если представить себе, что все 75 миллионов пользователей Firefox (или даже больше, если рост их числа продолжится существующими темпами) обновят свою версию браузера до 3.0, то в мире будет насчитываться 75 миллионов установленных и готовых к использованию копий XULRunner. Это, разумеется, учитывалось разработчиками Firefox, которые обеспечили доступ к XULRunner внутри Firefox 3.0 для сторонних приложений. Добавив ключ -app , можно будет запустить один лишь XULRunner вместо самого Firefox.

Разработка с помощью XUL

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

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

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

Илон Маск рекомендует:  Область видимости переменной

Самое важное — это структура каталогов XUL-приложения. Ниже вы начнете создавать приложение под названием xulblogger. Его структура приведена на рисунке 2.

На рисунке 2 показаны три ключевых файла. Первый — это application.ini, который должен находиться к корневом каталоге приложения. Основная функция этого файла — сообщить среде исполнения XUL, какая версия среды необходима для работы приложения. Содержимое файла приведено в листинге 1.

Следующий важный файл — это chrome.manifest, который должен быть в каталоге «chrome». Как правило, имеет смысл создать подкаталог внутри «chrome» и поместить туда все необходимые файлы XUL. Этот подкаталог может называться как угодно, например, «xulblogger» как в нашем приложении, хотя многие разработчики предпочитают «content». Попросту говоря, chrome.manifest сообщает среде исполнения XUL где находятся файлы вашего приложения. Пример приведен в листинге 2.

Как видите, потребовалась всего одна строчка. И, наконец, последний файл — это prefs.js, расположенный в каталоге /defaults/preferences. В нем хранится информация о том, какие XUL-файлы должны быть загружены при инициализации, как показано в листинге 3.

Также отметьте каталоги «extensions» и «updates». Они создаются автоматически, так что об этом можно не беспокоиться.

Еще один важный момент, связанный со структурой каталогов: приложения XUL, как правило, поставляются в виде JAR-файла, содержащего все каталоги, начиная с корневого. JAR может быть создан с помощью команды jar в случае установленной среды разработки Java, или же просто путем архивирования с помощью zip и последующего переименования расширения файла в .jar.

Существуют несколько способов запуска приложений XUL:

  • Для простого тестирования интерфейса достаточно просто открыть файлы с расширением .xul в Firefox (или же в любом другом браузере на основе Mozilla, таком как Seamonkey или Camino в Mac OS X). Как правило, это самый простой способ проверить в деле маленькое приложение. Правда Firefox ничего не знает о существовании файла chrome.manifest, так что если вы ссылаетесь в нем на другие файлы chrome, то Firefox их не найдет.
  • Другой способ заключается в использовании XULRunner. Его можно собрать из исходников (в этом случае заодно скомпилируется и Gecko SDK) или же скачать программу-установщик. После установки достаточно просто передать в XULRunner путь к файлу application.ini. После этого XULRunner проинициализирует приложение, используя информацию в application.ini и двух других конфигурационных файлах.
  • Наконец, если вам хочется быть впереди планеты всей, то можно скачать одну и внутренних сборок Firefox 3.0. В этом случае все будет очень похоже на работу с XULRunner. Все что нужно — это заменить строку запуска xulrunner

/application.ini на firefox -app

Редактор блогов

Теперь, когда среда разработки XUL сконфигурирована, пора заняться разработкой приложения. Мы напишем простой редактор блогов с возможностями создания и предпросмотра новых записей. Кроме этого, редактор будет позволять сохранять созданные записи на локальном диске с целью последующей загрузки в блог. Интерфейс редактора будет сделан на основе XUL, все остальное будет реализовано с помощью JavaScript. Начнем с интерфейса.

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

Интерфейс и вправду очень прост. Отметим легкость размещения элементов, которую обеспечивают компоненты vbox и hbox. vbox располагает элементы по вертикали, друг над другом, а hbox — по горизонтали, слева направо. Кроме них интерфейс состоит из пары текстовых меток, полей для ввода текста (в том числе и одного многстрочного), а также двух кнопок. После запуска приложения интерфейс должен выглядеть как на рисунке 5.

Вы могли заметить, что в листинге 4 присутствует еще и HTML-тег div под названием «preview». Он определяет область для предварительного просмотра созданной записи. Пользователь может напрямую редактировать HTML-код записи, а затем нажать на кнопку «preview» и посмотреть, что получилось. Пример приведен на рисунке 4.

Но каким образом HTML-код создаваемой записи интерпретируется и отображается в области для предварительного просмотра? Если вы посмотрите в код на XUL, то увидите, что при нажатии на кнопку «Preview» происходит вызов функции preview() . Тело функции из файла blog.js приведено в листинге 5.

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

Наверное, вы заметили, что в листинге 4 объявлены два пространства имен. Одно из них — это xul, которое использовалось ранее при определении каждого из элементов UI в файле XUL. При этом пространство имен по умолчанию указывает на HTML-схему. Обычно все бывает строго наоборот: пространством по умолчанию является XUL, а определению всех элементов HTML должен предшествовать префикс. Однако в данном случае необходимо, чтобы автор блога мог напрямую редактировать код записи на HTML. В противном случае пришлось бы разбирать содержимое панели предварительного просмотра и добавлять префикс html (или тот, что вы решили использовать) к каждому тегу перед его отображением.

Пока что приложение выглядит несколько убого, но улучшить его внешний вид весьма просто — достаточно просто добавить немного CSS, как это делается для обычных Web-страниц. Можно определять классы и идентификаторы для каждого виджета. Кроме этого, можно писать селекторы CSS, используя классы, или применять стили к конкретному виджету по его идентификатору. Все работает точно так же, как и в случае Web-страниц.

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

Первым делом необходимо разрешить использование XPConnect, который позволяет получить дескриптор компонента XPCOM. В данном случае в роли такого компонента выступает класс org.file.local в составе Mozilla. После этого можно вызывать методы объекта, как если бы он и правда исполнялся на локальной машине. Возможно, вы заметили вызов метода serialize() . Он необходим для сериализации содержимого записи в строку JSON, как показано в листинге 7.

Далее, как и раньше, используются обычные методы DOM в JavaScript для получения данных из созданной формы. Затем данные помещаются в специальную структуру на JavaScript, которая трансформируется в строку с помощью библиотеки JSON из json.org. Все что остается — это взять эту строку и записать ее в файл. Но в какой файл? В листинге 8 показан код определения файла для сохранения записи.

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

/blogentry.txt. Так что не стесняйтесь задействовать XPCOM для получения всех преимуществ XUL. Например, вышеприведенный фрагмент кода решает еще и потенциальную проблему, связанную с некорректными путями при сохранении данных.

Теперь, когда вы можете сохранять данные на диск, как насчет чтения? Как вы могли заметить на рисунке 1, при запуске приложения вызывается функция JavaScript read() . Ее тело показано в листинге 9.

Как и ранее, мы используем XPConnect для доступа к локальным библиотекам, развернутым через XPCOM. Теперь мы используем API того же компонента, что и для записи (см. листинг 6), только в этот раз — для чтения файла. Кроме этого, мы будем вызывать функцию deserialize() , как показано в листинге 10.

Эта функция тоже использует библиотеку JSON, только в данном случае берется строка из файла на локальном диске и трансформируется в объект JavaScript. Далее свойства объекта используются для установки соответствующих значений элементов управления UI.

К этому моменту наше приложение уже позволяет считывать и сохранять записи на локальный диск, а также делать предварительный просмотр создаваемой записи в виде HTML. Следующий шаг — это добавить обращение к Web-сервису для публикации записи в онлайн-блоге. Для этого можно использовать XPConnect и XPCOM для доступа к сетевому API, поставляемому вместе с XUL. В качестве альтернативы можно вызывать Web-сервис напрямую из JavaScript, т.е. используя объект XMLHttpRequest . Этот объект доступен внутри любой функции JavaScript в XUL, точно так же, как если бы она исполнялась внутри браузера. Пример приведен в листинге 11.

Самое главное здесь — это то, что точно такой же код вы бы писали, если бы надо было просто делать Ajax-вызовы из Web-страницы. Серьезным отличием является только то, что вам не надо беспокоиться о различиях в версиях Internet Explorer, Firefox (а также Safari, Opera и других браузеров). Это сильно упрощает работу с XMLHttpRequest .

Мы только создали простое настольное приложение с помощью XUL. XUL открывает целый мир новых возможностей для Web-разработчиков. В их числе возможности для решения более узко специализированных задач, таких, например, как написание модулей расширений для Firefox и других браузеров на основе Mozilla.

Написание расширений Firefox — это одно из наиболее популярных направлений программирования на XUL. Существует несколько серьезных различий между разработкой настольных приложения и написанием расширений. Из них наиболее важным является то, что расширения требуют наличия специального файла-манифеста, обязанного называться install.rdf и расположенного в корневом каталоге приложения. В этом файле находится репозиторий метаданных о модуле расширения. Плюс вам может понадобиться иконка для вашего расширения. В этом случае придется создать файл-картинку (.ico на платформе Windows и .xpm в случае Linux) и поместить его в /chrome/icons/default/. Имя файла должно совпадать с идентификатором главного окна расширения. Например, если идентификатор окна «xulBloggerMain», то файл должен называться xulBloggerMain.ico или xulBloggerMain.xpm.

Чем дольше вы занимаетесь разработкой на XUL, тем выше шансы, что в один прекрасный день вам понадобится собственный компонент XPCOM. Для его создания вам понадобится Gecko SDK, который вы можете скачать или же собрать из исходников. SDK содержит множество заголовочных файлов C++ и IDL, описывающих базовые XPCOM-компоненты Gecko, а также утилит командной строки, предназначенных для создания собственных компонентов XPCOM.

Прочитав данное руководство, вы узнали о возможностях XUL и его архитектуре, а также создали простое приложение. Было продемонстрировано, как разработчики могут приложить свои знания и опыт Web-разработок к созданию настольных приложений с помощью XUL. Подобные приложения вскоре станут доступны огромному количеству пользователей Firefox, в связи с намеченным релизом Firefox 3.0, включающего в себя среду исполнения XUL.

1. Описание пользовательского интерфейса

Интерфейс программы построен по стандартным схемам, используемых в подобных приложениях на мобильных телефонах. Данный раздел помощи подробно описывает все элементы управления и способы работы с ними.

1.1. Экран приложения

1. Заголовок окна. В заголовке содержится информация о том, в каком разделе находится пользователь;

2. Основная область. Основная рабочая область окна. В данном случае это таблица котировок;

3. Полоса прокрутки, которая показывает текущую позицию относительно полного размера основной области окна. Черная толстая полоса показывает текущее положение.

4 и 5. Кнопки меню или действий. Их выбор осуществляется нажатием соответствующей софт клавиши вашего телефона

6. Монитор сетевой активности. Похож на подобный в Windows. Может быть в пяти состояниях.

7. Индикаторы управления. Показывают, какие кнопки на джойстике (навигационной кнопке) телефона могут быть нажаты.

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

Полоса прокрутки. Монитор сетевой активности.
  • Нет обмена;
  • Передача данных или запроса серверу;
  • Прием данных от сервера;
  • Одновременная передача и прием;

  • Нет соединения.

В программе используются следующие элементы управления:

  • Поля ввода;
  • Радиокнопки;
  • Кнопки выбора;
  • Меню;
  • Списки;
  • Таблицы.

1.2. Поля ввода

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

Поля ввода. Ввод значения.

Редактирование поля ввода начинается при нажатии на кнопку выбора (обычно это центральное нажатое положение джойстика). При этом на полный экран мобильного телефона раскрывается форма, подобная той что изображена выше. Внешний вид этого экрана может незначительно отличаться в зависимости от модели телефона. Например, владельцы телефонов фирмы «Nokia» увидят горизонтальные разделительные полосы между строками. Закончить ввод можно нажав кнопку «Запомнить».

Поле, выбранное в данный момент обводится голубой рамкой.

При нажатии кнопки выбора вы будете редактировать именно это поле. Навигация по элементам управления осуществляется кнопками «Вверх» и «Вниз» вашего мобильного телефона.

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

1.3. Радиокнопки

Радиокнопки — элемент управления, который позволяет пользователю выбрать один вариант из нескольких предложенных. Радиокнопки располагаются в группах. Внутри каждой группы пользователь может выбрать один вариант, используя кнопку выбора или кнопку «Вправо» или «Влево».

Помимо таких групп вы можете встретить группу радиокнопок в меню. Этот момент подробнее рассмотрен в разделе «меню».

1.4. Кнопки выбора

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

1.5. Меню

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

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

Помимо такого подхода иногда вы встретите меню с радиокнопками (см. радиокнопки). В таком случае нажатие на кнопку выбора означает выбор одной из радиокнопок.

1.6. Списки

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

В этом режиме кнопками «вверх» и «вниз» вы выбираете нужный пункт, а затем, нажатием кнопки «выбор» закрепляете выбранный пункт. При этом список сворачивается, и его текст меняется на выбранный вами пункт.

1.7. Таблицы

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

Навигация по таблице осуществляется кнопками направления (на рисунке выше курсор стоит в ячейке «Начальный баланс». Ячейка таблицы, на которой установлен курсор, имеет более толстую границу).

В некоторых таблицах при нажатии на кнопку «Выбор» происходит какое-либо действие. Например, при нажатии кнопки «Выбор» в таблице котировок вы перейдете в режим сделки. При этом если в таблице вы находились в столбце Ask, то по умолчанию вам будет предложено купить валюту, а если в столбце Bid — то продать.

Реферат — Виды пользовательских интерфейсов и средства их разработки

Скачивание файла

Введите число с картинки:

1.ПОНЯТИЕ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ

2. ВИДЫ ИНТЕРФЕЙСОВ

2.1 Командный интерфейс

2.2 Графический интерфейс

2.2.1 Простой графический интерфейс

2.2.2 WIMP – интерфейс

2.3 Речевая технология

2.4 Биометрическая технология

2.5 Семантический (общественный) интерфейс

2.6 Типы интерфейсов

3. МЕТОДЫ И СРЕДСТВА РАЗРАБОТКИ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

3.2 Язык и интерпретатор Tcl/Tk

3.3 Microsoft Expression Blend – инструмент создания интерфейсов

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

1. ПОНЯТИЕ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ

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

Интерфейс — в широком смысле слова, это способ (стандарт) взаимодействия между объектами. Интерфейс в техническом смысле слова задаёт параметры, процедуры и характеристики взаимодействия объектов. Различают:

Интерфейс пользователя — набор методов взаимодействия компьютерной программы и пользователя этой программы.

Программный интерфейс — набор методов для взаимодействия между программами.

Физический интерфейс — способ взаимодействия физических устройств. Чаще всего речь идёт о компьютерных портах.

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

Рисунок 1. Взаимодействие пользователя с компьютером

В основном пользователь генерирует сообщения следующих типов:

запрос операции или функции

ввод или изменение информации

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

Интерфейс пользователя компьютерного приложения включает:

средства отображения информации, отображаемую информацию, форматы и коды;

командные режимы, язык «пользователь — интерфейс»;

устройства и технологии ввода данных;

диалоги, взаимодействие и транзакции между пользователем и компьютером, обратную связь с пользователем;

поддержку принятия решений в конкретной предметной области;

порядок использования программы и документацию на неё.

Пользовательский интерфейс (ПИ) часто понимают только как внешний вид программы. Однако на деле пользователь воспринимает через него всю программу в целом, а значит, такое понимание является слишком узким. В действительности ПИ объединяет в себе все элементы и компоненты программы, которые способны оказывать влияние на взаимодействие пользователя с программным обеспечением (ПО).

Это не только экран, который видит пользователь. К этим элементам относятся:

набор задач пользователя, которые он решает при помощи системы;

используемая системой метафора (например, рабочий стол в MS Windows®);

элементы управления системой;

навигация между блоками системы;

визуальный (и не только) дизайн экранов программы;

средства отображения информации, отображаемая информация и форматы;

устройства и технологии ввода данных;

диалоги, взаимодействие и транзакции между пользователем и компьютером;

обратная связь с пользователем;

поддержка принятия решений в конкретной предметной области;

порядок использования программы и документация на нее.

2. ВИДЫ ИНТЕРФЕЙСОВ

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

Современными видами интерфейсов являются:

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

2) WIMP — интерфейс (Window — окно, Image — образ, Menu — меню, Pointer — указатель). Характерной особенностью этого вида интерфейса является то, что диалог с пользователем ведется не с помощью команд, а с помощью графических образов — меню, окон, других элементов. Хотя и в этом интерфейсе подаются команды машине, но это делается «опосредственно», через графические образы. Этот вид интерфейса реализован на двух уровнях технологий: простой графический интерфейс и «чистый» WIMP — интерфейс.

3) SILK — интерфейс (Speech — речь, Image — образ, Language — язык, Knowlege — знание). Этот вид интерфейса наиболее приближен к обычной, человеческой форме общения. В рамках этого интерфейса идет обычный «разговор» человека и компьютера. При этом компьютер находит для себя команды, анализируя человеческую речь и находя в ней ключевые фразы. Результат выполнения команд он также преобразует в понятную человеку форму. Этот вид интерфейса наиболее требователен к аппаратным ресурсам компьютера, и поэтому его применяют в основном для военных целей.

2.1 Командный интерфейс

Пакетная технология. Исторически этот вид технологии появился первым. Она существовала уже на релейных машинах Зюса и Цюзе (Германия, 1937 год). Идея ее проста: на вход компьютера подается последовательность символов, в которых по определенным правилам указывается последовательность запущенных на выполнение программ. После выполнения очередной программы запускается следующая и т.д. Машина по определенным правилам находит для себя команды и данные. В качестве этой последовательности может выступать, например, перфолента, стопка перфокарт, последовательность нажатия клавиш электрической пишущей машинки (типа CONSUL). Машина также выдает свои сообщения на перфоратор, алфавитно-цифровое печатающее устройство (АЦПУ), ленту пишущей машинки. Такая машина представляет собой «черный ящик» (точнее «белый шкаф»), в который постоянно подается информация и которая также постоянно «информирует» мир о своем состоянии (см. рисунок 1) Человек здесь имеет малое влияние на работу машины — он может лишь приостановить работу машины, сменить программу и вновь запустить ЭВМ. Впоследствии, когда машины стали помощнее и могли обслуживать сразу нескольких пользователей, вечное ожидание пользователей типа: «Я послал данные машине. Жду, что она ответит. И ответит ли вообще? » — стало, мягко говоря, надоедать. К тому же вычислительные центры, вслед за газетами, стали вторым крупным «производителем» макулатуры. Поэтому с появлением алфавитно-цифровых дисплеев началась эра по-настоящему пользовательской технологии — командной строки.

Рис.2. Вид большой ЭВМ серии ЕС ЭВМ

Технология командной строки. При этой технологии в качестве единственного способа ввода информации от человека к компьютеру служит клавиатура, а компьютер выводит информацию человеку с помощью алфавитно-цифрового дисплея (монитора). Эту комбинацию (монитор + клавиатура) стали называть терминалом, или консолью. Команды набираются в командной строке. Командная строка представляет собой символ приглашения и мигающий прямоугольник — курсор. При нажатии клавиши на месте курсора появляются символы, а сам курсор смещается вправо. Это очень похоже на набор команды на пишущей машинке. Однако, в отличие от нее, буквы отображаются на дисплее, а не на бумаге, и неправильно набранный символ можно стереть. Команда заканчивается нажатием клавиши Enter (или Return) После этого осуществляется переход в начало следующей строки. Именно с этой позиции компьютер выдает на монитор результаты своей работы. Затем процесс повторяется. Технология командной строки уже работала на монохромных алфавитно-цифровых дисплеях. Поскольку вводить позволялось только буквы, цифры и знаки препинания, то технические характеристики дисплея были не существенны. В качестве монитора можно было использовать телевизионный приемник и даже трубку осциллографа.


Обе эти технологии реализуются в виде командного интерфейса — машине подаются на вход команды, а она как бы «отвечает» на них.

Преобладающим видом файлов при работе с командным интерфейсом стали текстовые файлы — их и только их можно было создать при помощи клавиатуры. На время наиболее широкого использования интерфейса командной строки приходится появление операционной системы UNIX и появление первых восьмиразрядных персональных компьютеров с многоплатформенной операционной системой CP / M.

2.2 Графический интерфейс

Как и когда появился графический интерфейс? Его идея зародилась в середине 70-х годов, когда в исследовательском центре Xerox Palo Alto Research Center (PARC) была разработана концепция визуального интерфейса. Предпосылкой графического интерфейса явилось уменьшение времени реакции компьютера на команду, увеличение объема оперативной памяти, а также развитие технической базы компьютеров. Аппаратным основанием концепции, конечно же, явилось появление алфавитно-цифровых дисплеев на компьютерах, причем на этих дисплеях уже имелись такие эффекты, как «мерцание» символов, инверсия цвета (смена начертания белых символов на черном фоне обратным, то есть черных символов на белом фоне), подчеркивание символов. Эти эффекты распространились не на весь экран, а только на один или более символов. Следующим шагом явилось создание цветного дисплея, позволяющего выводить, вместе с этими эффектами, символы в 16 цветах на фоне с палитрой (то есть цветовым набором) из 8 цветов. После появления графических дисплеев, с возможностью вывода любых графических изображений в виде множества точек на экране различного цвета, фантазии в использовании экрана вообще не стало границ! Первая система с графическим интерфейсом 8010 Star Information System группы PARC, таким образом, появилась за четыре месяца до выхода в свет первого компьютера фирмы IBM в 1981 году. Первоначально визуальный интерфейс использовался только в программах. Постепенно он стал переходить и на операционные системы, используемых сначала на компьютерах Atari и Apple Macintosh, а затем и на IBM — совместимых компьютерах.

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

2.2.1 Простой графический интерфейс

На первом этапе графический интерфейс очень походил на технологию командной строки. Отличия от технологии командной строки заключались в следующим:

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

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

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

4. Кроме клавиши Enter, на клавиатуре все чаще стали использоваться «серые» клавиши управления курсором.

5. Уже в этой редакции графического интерфейса стали использоваться манипуляторы (типа мыши, трекбола и т.п. — см. рис.3) Они позволяли быстро выделять нужную часть экрана и перемещать курсор.

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

1) Выделение областей экрана.

2) Переопределение клавиш клавиатуры в зависимости от контекста.

3) Использование манипуляторов и серых клавиш клавиатуры для управления курсором.

4) Широкое использование цветных мониторов.

Появление этого типа интерфейса совпадает с широким распространением операционной системы MS-DOS. Именно она внедрила этот интерфейс в массы, благодаря чему 80-е годы прошли под знаком совершенствования этого типа интерфейса, улучшения характеристик отображения символов и других параметров монитора.

Типичным примером использования этого вида интерфейса является файловая оболочка Nortron Commander (о файловых оболочках смотри ниже) и текстовый редактор Multi-Edit. А текстовые редакторы Лексикон, ChiWriter и текстовый процессор Microsoft Word for Dos являются примером, как этот интерфейс превзошел сам себя.

2.2.2 WIMP – интерфейс

Вторым этапом в развитии графического интерфейса стал «чистый» интерфейс WIMP, Этот подвид интерфейса характеризуется следующими особенностями.

1. Вся работа с программами, файлами и документами происходит в окнах — определенных очерченных рамкой частях экрана.

2. Все программы, файлы, документы, устройства и другие объекты представляются в виде значков — иконок. При открытии иконки превращаются в окна.

3. Все действия с объектами осуществляются с помощью меню. Хотя меню появилось на первом этапе становления графического интерфейса, оно не имело в нем главенствующего значения, а служило лишь дополнением к командной строке. В чистом WIMP — интерфейсе меню становится основным элементом управления.

4. Широкое использование манипуляторов для указания на объекты. Манипулятор перестает быть просто игрушкой — дополнением к клавиатуре, а становится основным элементом управления. С помощью манипулятора УКАЗЫВАЮТ на любую область экрана, окна или иконки, ВЫДЕЛЯЮТ ее, а уже потом через меню или с использованием других технологий осуществляют управление ими.

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

Ярким примером программ с графическим интерфейсом является операционная система Microsoft Windows.

2.3 Речевая технология

С середины 90-х годов, после появления недорогих звуковых карт и широкого распространения технологий распознавания речи, появился так называемый «речевая технология» SILK — интерфейса. При этой технологии команды подаются голосом путем произнесения специальных зарезервированных слов — команд. Основными такими командами (по правилам системы «Горыныч») являются:

«Проснись» — включение голосового интерфейса.

«Отдыхай» — выключение речевого интерфейса.

«Открыть» — переход в режим вызова той или иной программы. Имя программы называется в следующем слове.

«Буду диктовать» — переход из режима команд в режим набора текста голосом.

«Режим команд» — возврат в режим подачи команд голосом.

и некоторые другие.

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

«Речевая» технология является простейшей реализацией SILK — интерфейса.

2.4 Биометрическая технология

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

2.5 Семантический (общественный) интерфейс

Этот вид интерфейса возник в конце 70-х годов XX века, с развитием искусственного интеллекта. Его трудно назвать самостоятельным видом интерфейса — он включает в себя и интерфейс командной строки, и графический, и речевой, и мимический интерфейс. Основная его отличительная черта — это отсутствие команд при общении с компьютером. Запрос формируется на естественном языке, в виде связанного текста и образов. По своей сути это трудно называть интерфейсом — это уже моделирование «общения» человека с компьютером. С середины 90-х годов XX века публикации, относящихся к семантическому интерфейсу, уже не встречались. Похоже, что в связи с важным военным значением этих разработок (например, для автономного ведения современного боя машинами — роботами, для «семантической» криптографии) эти направления были засекречены. Информация, что эти исследования продолжаются, иногда появляется в периодической печати (обычно в разделах компьютерных новостей).

2.6 Типы интерфейсов

Интерфейсы пользователя бывают двух типов:

-со свободной навигацией

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

Объектно-ориентированные интерфейсы используют модель взаимодействия с пользователем, ориентированную на манипулирование объектами предметной области. В рамках этой модели пользователю предоставляется возможность напрямую взаимодействовать с каждым объектом и инициировать выполнение операций, в процессе которых взаимодействуют несколько объектов. Задача пользователя формулируется как целенаправленное изменение некоторого объекта. Объект понимается в широком смысле слова — модель БД, системы и т.д. Объектно-ориентированный интерфейс предполагает, что взаимодействие с пользователем осуществляется посредством выбора и перемещения пиктограмм соответствующей объектно-ориентированной области. Различают однодокументные (SDI) и многодокументные (MDI) интерфейсы.

1) Обеспечивают пользователю функции, необходимые для выполнения задач;

2) Акцент делается на задачи;

3) Пиктограммы представляют приложения, окна или операции;

4) Содержание папок и справочников отражается с помощью таблицы-списка.

1) Обеспечивает пользователю возможность взаимодействия с объектами;

2) Акцент делается на входные данные и результаты;

3) Пиктограммы представляют объекты;

4) Папки и справочники являются визуальными контейнерами объектов.

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

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

каждое окно меню занимает весь экран

на экране одновременно присутствуют несколько разноуровневых меню (Windows).

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

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

3. МЕТОДЫ И СРЕДСТВА РАЗРАБОТКИ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

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

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

В литературе не существует единой общепринятой классификации средств для разработки пользовательского интерфейса. Так, программное обеспечение для разработки пользовательского интерфейса можно разделить на две основные группы — инструментарий для разработки пользовательского интерфейса (toolkits) и высокоуровневые средства разработки интерфейса (higher-level development tools). Инструментарий для разработки пользовательского интерфейса, как правило, включает в себя библиотеку примитивов компонентов интерфейса (меню, кнопки, полосы прокрутки и др.) и предназначен для использования программистами. Высокоуровневые средства разработки интерфейса могут быть использованы непрограммистами и снабжены языком, который позволяет специфицировать функции ввода-вывода, а также определять, используя технику непосредственного манипулирования, интерфейсные элементы. К таким средствам относятся построители диалога (interface builders) и СУПИ — системы управления пользовательским интерфейсом (User Interface Management Systems — UIMS). Помимо СУПИ, некоторые авторы используют такие термины, как User Interface Development Systems (UIDS) — системы разработки пользовательского интерфейса, User Interface Design Environment (UIDE) — среда разработки пользовательского интерфейса и др.

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

1. Языковой, когда применяются специальные языки для задания синтаксиса интерфейса (декларативные, объектно-ориентированные, языки событий и др.).

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

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

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

Основной концепцией СУПИ является отделение разработки пользовательского интерфейса от остального приложения. В настоящее время идея раздельного проектирования интерфейса и приложения либо закреплена в определении СУПИ либо является основным его свойством.

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

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

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

Основное назначение тех средств разработки пользовательских графических интерфейсов, которые разрабатываются и поставляются отдельно от оконной системы, является облегчение создания нового графического интерфейса за счет использования существующих параметризованных заготовок. Как видно, в принципе это те же самые идеи, на которых основана объектно-ориентированная библиотека оконной системы X Xt Intrinsics.

И действительно, наиболее распространенный пакет, предназначенный для быстрой и качественной разработки графических пользовательских интерфейсов, Motif, который был спроектирован и разработан в северо-американском консорциуме OSF, в основном является развитием идей Xt Intrinsics. Motif является сугубо коммерческим продуктом. Дело дошло до того, что компания OSF запатентовала внешний интерфейс продуктов, входящих в состав Motif, чтобы не дать кому-нибудь возможность воспроизвести этот интерфейс.

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

С другой стороны, сравнительно недавно (4-5 лет тому назад) в Калифорнийском университете г. Беркли был создан альтернативный механизм под названием Tcl/Tk. Этот механизм основан на наличии специализированного командного языка, предназначенного для описания графических пользовательских интерфейсов, соответствующего интерпретатора и библиотеки ранее разработанных заготовок интерфейсов. Пакет Tcl/Tk распространяется (вместе с полной документацией) свободно, и многие профессиональные программисты находят его более удобным, чем Motif.

Motif (официальное название этого продукта — OSF/Motif) представляет собой программный пакет, включающий оконный менеджер, набор вспомогательных утилит, а также библиотеку классов, построенных на основе Xt Intrinsics. Для конечных пользователей оконных систем, опирающихся на Motif, основной интерес представляет менеджер окон, хотя, скорее всего, вы не сможете определить, применяется ли оконный менеджер Motif в используемой вами установке.

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

Библиотека классов Motif является расширением библиотеки Xt Intrinsics с целью предания этой библиотеке практического смысла (по-другому можно сказать, что Motif — это то, чем должен был бы быть Xt, если бы при его создании ставились коммерческие цели). Все графические объекты (правильнее сказать, классы) Xt Intrinsics включаются в библиотеку классов Motif, хотя в ней используются другие имена.

Но Motif существенно расширяет возможности Xt Intrinsics. В его библиотеке поддерживается большое число классов, позволяющих создавать меню, «нажимаемые» кнопки и т.д. Основное назначение этих классов — определение новых виджетов, связанных с окнами.

Однако в Motif поддерживается и новый вид графических объектов (их классов) — так называемые гаджеты (gadgets). Гаджет отличается от виджета тем, что соответствующий класс также может использоваться для создания элементов интерфейса, но графический объект не привязывается к определенному окну. При отображении на экран гаджета используется окно объекта, относящегося к суперклассу класса гаджета.

Понятно, что здесь мы не можем привести подробное описание Motif (еще раз повторим, что соответствующий материал содержится в нескольких солидных книгах). Однако основная идея должна быть понятна: развитая библиотека классов языка Си++, возможности применения этих классов при использовании обычного стиля программирования и поддержка визуального программирования с немедленным отображением получающихся графических объектов.

3.2 Язык и интерпретатор Tcl/Tk


Продукт Tcl/Tk в действительности представляет собой два связанных программных пакета, которые совместно обеспечивают возможность разработки и использования приложений с развитым графическим пользовательским интерфейсом. Название Tcl относится к «командному языку инструментальных средств — tool command language», и, как не странно, его рекомендуется произносить «тикл». Это простой командный язык для управления приложениями и расширения их возможностей. Язык Tcl является «встраиваемым»: его интерпретатор реализован в виде библиотеки функций языка Си, так что интерпретатор может быть легко пристыкован к любой прикладной программе, написанной на языке Си.

Tk (рекомендуемое произношение — «ти-кей») является библиотекой Си-функций, ориентированной на облегчение создания пользовательских графических интерфейсов в среде оконной системы X (т.е., по сути дела, некоторый аналог Xt Intrinsics). С другой стороны, аналогично тому, как это делается в командных языках семейства shell, функции библиотеки Tk являются командами языка Tcl, так что любой программист может расширить командный репертуар языка Tcl путем написания новой функции на языке Си.

Совместно, Tcl и Tk обеспечивают четыре преимущества для разработчиков приложений и пользователей (мы используем здесь авторские тексты разработчиков). Во-первых, наличие командного языка Tcl дает возможность в каждом приложении использовать мощный командный язык. Все, что требуется от разработчика приложения, чтобы удовлетворить его/ее специфические потребности, — это создать несколько новых команд Tcl, требующихся приложению (и, возможно, другим приложениям — явно традиционный стиль командного программирования в ОС UNIX). После этого нужно связать прикладную программу с интерпретатором Tcl и пользоваться полными возможностями командного языка.

Вторым преимуществом использования Tcl/Tk является возможность быстрой разработки графических интерфейсов. Многие интересные оконные приложения могут быть написаны в виде скриптов языка Tcl без привлечения языков Си или Си++ (а Tcl позволяет скрыть многие несущественные детали). Как утверждают разработчики Tcl/Tk, пользователи оказываются способными к созданию новых графических интерфейсов уже после нескольких часов знакомства с продуктом. Другой особенностью языка Tcl, способствующей быстрой разработке оконных приложений, является то, что язык является интерпретируемым. Можно опробовать новую идею интерфейса, выражающуюся в сотнях или тысячах строк кода на языке Tcl, без потребности вызова новых программных средств, путем простого нажатия на клавишу мыши (не наблюдая существенных задержек при использовании современных рабочих станций).

Третьим преимуществом языка Tcl является то, что его можно применять в качестве языка «склейки» приложений. Например, любое основанное на Tcl и использующее Tk оконное приложение может направить свой скрипт любому другому аналогично ориентированному приложению. С использованием Tcl/Tk можно создавать приложения, работающие в стиле мультимедиа, и опять же они смогут обмениваться скриптами, поскольку пользуются общим интерпретатором командного языка Tcl и общей внешней библиотекой Tk.

Наконец, четвертым удобством интегрированного пакета Tcl/Tk является удобство пользователей. Для написания нового приложения в среде Tcl/Tk достаточно выучить несколько совершенно необходимых команд, и этого окажется достаточно. Другими словами оказывается возможным инкрементальный (пошаговый) стиль погружения в предмет. Такая возможность всегда радует сердце и греет душу.

Впрочем, заметим, что далеко не все программисты разделяют выраженное выше глубоко радостное отношение разработчиков Tcl/Tk к своему продукту.

3.3 Microsoft Expression Blend – инструмент создания интерфейсов

Появление языка описания пользовательских интерфейсов XAML (произносится – зáммель) и новой среды разработки Expression Blend позволяет заметно ускорить и облегчить проектирование и построение пользовательских интерфейсов как для веб-, так и для настольных приложений.

Данный язык позволяет описывать внешний вид и поведение интерфейсных элементов, устанавливать взаимодействие этих элементов с различными данными и событиями. Допускает прямое подключение к Common Language Runtime (CLR), что обеспечивает большую гибкость при проектировании ПО.

Функциональность, взаимодействие XAML и процедурного кода

XAML – это скриптовый язык, базирующийся на XML, он имеет набор правил, которые устанавливают взаимодействие между объектами и классами, атрибутами и свойствами или событиями и пространствами имен XML и CLR. Для описания элементов, панелей, свойств текста, векторной графики и т.п. используются теги.

Каждый тег в XAML имеет соответствующий класс в WPF, который имеет набор инструкций, как выполнить этот тег. XAML включает в себя: панели, элементы управления, элементы управления документами и элементы векторной графики.

При создании проекта в Expression Blend каждый файл на XAML имеет файл-соратник (code-behind) на C# или VB.

XAML взаимодействует с кодом на C# или VB посредством обработчика событий, который прописывается внутри тега объекта.

Пример обработчика события Button_Click на C#

private void Button_Click(object sender, System.Windows.RoutedEventArgs e)

MessageWindow MessageWindow = new MessageWindow();

Microsoft Expression Blend

Есть несколько визуальных редакторов позволяющих создавать и редактировать XAML: Microsoft XamlPad, Microsoft Visual Studio 2005, 2008, Microsoft Expression Blend, Mobiform Avrora, XamlHack.

Подробно хочу остановиться на основном приложении для работы с XAML – Microsoft Expression Blend, далее просто Blend.

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

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

Blend имеет современный интерфейс, привычный как дизайнерам графикам, так и веб-дизайнерам.

Рабочее пространство разделено на три основные части.

Рисунок 4 — Рабочее пространство Microsoft Expression Blend

Панель инструментов (подкрашена красным), панели Interaction и Objects and Timeline (пурпурным) слева, основное рабочее пространство с панелью инструментов и вкладками переключения вида Design, XAML или Split посередине и панель Results в центре снизу (подкрашено зеленым) и панели Project, Properties, Resourses и Data справа (синие).

Все панели позволяют переключаться в «плавающий» режим или исчезать с экрана при помощи «горячих» клавиш. В меню Tools/Options/Workspace есть возможность настройки размеров панелей. Blend использует большое количество «горячих» клавиш, спасибо разработчикам о заботе, большинство сочетаний хорошо известны всем дизайнерам, работающим с графическими программами от Adobe.

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

По умолчанию в Blend включены две библиотеки интерфейсных элементов System Controls – стандартные элементы и Simple Styles – библиотека-пример построения пользовательских интерфейсных элементов, раскрывающая возможности XAML.

Векторный редактор Blend обладает всеми возможностями современного векторного редактора плюс обладает некоторыми уникальными свойствами.

Инструменты для построения и редактирования векторной графики типичны для многих векторных редакторов и включают в себя редактор кривых, представленный инструментами: Перо (Pen), Карандаш (Pencil), инструмент выделения (Selection) и инструмент непосредственного выделения (Direct Selection), а также инструментами для построения простых геометрических форм: Прямоугольник (Rectangle), Овал (Ellipse) и Линия (Line).

создавать составные векторные объекты (Compound paths);

создавать векторные объекты посредством логических операций (вычитание, сложение и т.д.) (Combining paths);

переводить шрифт в векторный объект (Convert to Path);

кадрировать как растровое, так и векторное изображение (Clipping paths);

создавать маски прозрачности (Opacity masks).

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

Остановимся подробнее на некоторых из них:

Возможность раздельно задавать толщину линий образующих стороны объектов типа Граница (Border) и Прямоугольник (Rectangle).

Возможность раздельно задавать радиус скругления для всех углов в объекте Граница (Border).

Рисунок 5 — Пример построения пользовательского элемента с кодом на XAML

Настройка внешнего вида объектов

Внешний вид объектов зависит от свойств, которые задаются как при помощи прямых настроек, так и при помощи кистей (Brushes):

Передний план (Foreground)

Маска прозрачности (Opacity masks)

Кисти используются для задания внешнего вида объектов и могут быть следующих типов:

Одноцветная кисть (Solid color brush)

Линейный градиент (Linear gradient brush)

Радиальный градиент (Radial gradient brush)

Кисть растровое изображение (Image brush)

Кисть векторное изображение (Drawing brush)

Кисть визуальных эффектов (Visual brush)

Кисти можно конвертировать в ресурсы и многократно применять к различным объектам.

Blend имеет стандартный редактор цветов позволяющий оперировать четырьмя цветовыми моделями: RGB, HLS, HSB и CMYK, а так же специальный инструмент для настройки градиентов (Brush transform tool) и инструменты для переноса свойств объектов (Eyedropper и Paint Bucket).

Особо бы хотелось отметить наличие в Blend специальных растровых эффектов (Bitmap effects):

Внешнее свечение (Outer glow)

Тень (Drop shadow)

Все фильтры работают в реальном масштабе времени и могут применяться ко всем без исключения интерфейсным элементам, в том числе и генерируемым «на лету».

Работа с текстом

Blend является специализированным инструментом для построения пользовательских интерфейсов и имеет несколько типов текстовых объектов:

Текстовое поле (TextBox)

Текстовое поле с расширенными возможностями (RichTextBox)

Текстовый блок (TextBlock)

Поле пароля (PasswordBox)

Текстовый блок с расширенным содержимым и полосой прокрутки (FlowDocumentScrollViewer)

Настройки текста зависят от типа объекта и его функциональности.

Библиотека интерфейсных элементов

Библиотека интерфейсных элементов содержит все типы стандартных интерфейсных элементов, специфические элементы Blend и элементы, содержащиеся в стиле SimpleStyles.

Рисунок 6 — Список интерфейсных элементов, доступных из встроенной библиотеки

Элементы подразделяются на следующие категории:

Панели разметки (Layout Panels), используются как контейнеры для других элементов, определяя их местоположение относительно друг друга.

Интерфейсные элементы (Controls).

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

Создание интерфейсов в Expression Blend

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

Стили и шаблоны

Стили и шаблоны уникальная возможность XAML, позволяющая сочетать в себе мощность стилей CSS и гибкость шаблонов графических программ.

Стили описываются содержимым заключенным в тег и могут содержать следующие элементы:

Кисти всех типов (Brush)

Геометрические свойства элементов (Высота, ширина, скругление углов, толщина линий и т.д.)

Специальные эффекты (BitmapEffects и Visual brush)

Векторные графические объекты.

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

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

Создание пользовательских интерфейсных элементов

Есть два пути для создания элементов: можно выучить синтаксис XAML и «писать» элементы кодом или же можно воспользоваться Blend. Второй способ проще, нагляднее и быстрее.

Для создания пользовательского вида интерфейсного элемента в Blend имеется возможность как редактирования существующего, так и создания нового элемента. Для того чтобы отредактировать элемент достаточно «щелкнуть» по нему правой кнопкой мыши и выбрать Edit Control Parts (Template). Появится «начинка» элемента и вы можете изменить внешний вид – с помощью графического редактора Blend или изменить поведение элемента, редактируя переключатели событий (Event Triggers) или задать анимацию, используя Timeline.

Разметка документа осуществляется специальными панелями (Layout Panels), которые могут включать в себя как сами панели, так и интерфейсные элементы. Доступ к панелям осуществляется на панели инструментов и что самое неожиданное, как функция Группировки (Group), наконец то группировка перестала быть абстрактной сущностью!

Панели разметки могут быть следующих типов:

Холст (Canvas panel)

Стыковочная панель (Dock panel), содержимое панели может пристыковываться к заданным сторонам панели

Таблица (Grid panel), содержимое находится внутри ячеек таблицы

Стопка (Stack panel), содержимое группируется в последовательном порядке по горизонтали или вертикали

Панель с возможностью скрытия содержимого (Wrap panel) – если содержимое не помещается внутри панели, например, при изменении размера панели, содержимое скрывается определенным образом.

Расположение объектов, привязки и выравнивание

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

Рисунок 7 — Визуальная привязка

Инструмент визуальной привязки (Snap) имеет уникальное свойство, а именно предопределяемое свойство показывать заданный размер границы между элементами (Default margin и Default padding). Эта функция здорово ускоряет расположение элементов в форме: достаточно просто выбросить элемент на плоскость и Blend сам покажет нужные для него отступы.

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

Функция выравнивания (Align) работает не совсем обычно: выравнивание элементов происходит не относительно друг друга, как это обычно практикуется в графических программах, а относительно Панели разметки (Layout Panels), в которой находятся элементы, что очень удобно, но непривычно. Если элементы находятся внутри Таблицы (Grid Panel), то появляется возможность управлять поведением элементов при изменении размеров окна приложения, имеется 3 вида поведения:

Auto – при изменении размеров таблицы изменяется размер заключенных в нее элементов.

Pixel – строка или столбец таблицы имеют фиксированное значение в пикселях.

Star – изменяет размеры элементов аналогично изменению размеров в процентах в HTML.

Данные свойства устанавливаются, как на строки, так и столбцы таблицы и могут применяться в любой комбинации.

Плюсы и минусы Expression Blend

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

Удобный минималистический интерфейс

Встроенный редактор векторной графики с разветвленным инструментарием

Встроенный редактор XAML с подсветкой синтаксиса

Наличие привычных для дизайнеров «горячих» клавиш

Наличие уникальных инструментов и интерфейсных решений

Программа предназначена для дизайнеров с хорошим знанием или отношением к XML подобным языкам разметки

Требует установки .NET Framework 3 или 3.5 (даже для просмотра готового проекта.exe) и еще желательно Visual Studio (для редактирования C# файлов)

Неустойчиво и медленно работает (Бета-версия).

Требует вмешательство в XAML код, т.к. не все свойства могут устанавливаться из графического интерфейса Blend.

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

Справочная система не достаточно проработана.

Разветвленная система файлов, необходимых для проекта.

Blend и классические способы создания прототипов интерфейсов

По большому счету, сравнение классических технологий прототипирования интерфейсов и новой технологии WPF – представителем которой является Blend, является не совсем корректным.

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

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

Что несет нам новая технология?

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

Векторная графика: теперь интерфейс состоит полностью из векторных объектов (интерфейсные элементы, графика, пиктограммы).

Новые экранные шрифты.

Новая технология попиксельного позиционирования изображения на экране.

Одна программа может содержать несколько интерфейсов (разные разрешения, веб и настольные приложения и т.д.).

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

Т.Б. Большаков, Д.В. Иртегов. Оперционные системы[Электронный ресурс]. Материалы сайта http: // www. citforum. ru / operating_systems / ois / introd. shtml.

Методы и средства разработки пользовательского интерфейса: современное состояние, Клещев А.С. , Грибова В.В. , 2001[Электронный ресурс]. Материалы сайта http: // www. swsys. ru / index. php? page=article& >

Дейтел Г. Введение в операционные системы. В двух томах / Пер, с англ. Л.А. Теп-лицкого, А.Б. Ходулева, В.С. Штаркмана под ред.В.С. Штаркмана.[текст] — М.: Мир, 1987.

Программная инженерия. Стандартизация пользовательского интерфейса. Евгений Волченков. М, 2002[Электронный ресурс]. Материалы сайта http: // tizer. adv. vz. ru.

Илон Маск рекомендует:  Что такое код createrectrgnindirect
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL