HTMLayout: Web 2.0 пришел на десктоп!

Моя давнишняя мечта – написать свою шареваре-программу и продавать ее через Интернет: обналичка, Бразилия, Мальдивы, Токио, пляжи, лыжи, казино… эххх. Этим летом я чуть не претворил ее в реальность… и все благодаря одному замечательному графическому движку. Скажу вам сразу – программу я так и не закончил (тупо не хватает времени), но лето провел не зря – теперь я знаю, КАКИЕ интерфейсы можно делать на десктопе. Для нас (HumanoIT Group) это знание – на вес золота, ведь мы проектируем интерфесы не только для веб-приложений.

HTMLayout это единственный в своем роде (на сегодняшний день) встраиваемый (embeddable) HTML/CSS engine.

Вот парочка интерфейсов, сделанных на базе движка HTMLayout:

Никто не расскажет про HTMLayout лучше, чем сам автор. Поэтому предлагаю вам интервью с Андреем Федонюком, автором этого замечательного графического движка.

Часть 1: Размышлизмы о Web 2.0

Расскажи немного о себе: чем занимаешься, где работаешь?
Terra Informatica. Вот этим и занимаюсь, там и работаю. Есть еще несколько контрактов долгоиграющих с основными клиентами.

Terra Informatica – это твоя компания?
Да.

Что ты думаешь о Web 2.0: что для тебя Web 2.0 как для пользователя? Как для программиста?
Ну во-первых, никто толком не знает, что такое Web 2.0 :) Набор технологий и решений на уровне “хака” – это да. Для себя я классифициурую Web 2.0 как набор технологий, поддерживающих Occasionally Connected Web Applications.

Поясни пожалуйста термин Occasionally Connected Web Applications?
Это приложение, в которое заложена возможность работать offline. Т.е. Web 2.0 – это больше про десктоп приложения, чем про web собственно. Т.е. про использование web на desktop и наоборот – привнесение черт десктоп приложений на web приложения

Назови пожалуйста основные различия между сегодняшними desktop-приложениями и Web 2.0-приложениями?
Храненние данных. В принципе – это старая как мир разница между client-server и desktop приложениями. Web 2.0 пытается привнести “комфортность” desktop на web.

А если с точки зрения UI, какова на твой взгляд разница? (если пока не брать в расчет HTMLAyout)
Inductive UI versus Productive UI. Традиционно Web application это occasionally used application. Т.е. UI web application должен быть self descriptive – пользователь с улицы должен мочь сделать то, что ему нужно без всяких доков.

Например Norton Antivirus или Norton Intenet Security – это приложения “одной большой красной кнопки” – используются редко и их UI должен быть понятен интуитивно. Поэтому (в том числе) Symantec используют HTMLayout в своих продуктах.

Что ты понимаешь под inductive ui? Это визарды, ориентация на пользовательские задачи?
Да, inductive ui – это парадигма “шагов” (визард) – введи данные, нажми submit, перейди к следующему шагу.

AC (Александр Сергеев): Кстати, Дон Норман ввел такое понятие, как affordance – аналог self descriptive, например, ножницы – понятно, что пальцы просунуть надо в дырки :)

АФ (Андрей Федонюк): Да.

А под productive UI ты что имеешь в виду?
Inductive UI это web 1.0. Web 2.0 – это (в том числе) попытка сделать возможным productive UI в web. Productive UI – это приложения, которые используются каждый день. Для такого типа приложений характерны приемы минимизации затрат на достижение результата пользователем. Shortcuts, например, явный атрибут productive UI – toolbars и прочее там же.

Но это разделение Inductive/Productive все более размытее становится. Сложность приложений растет, поэтому даже такие приложения как MS Word используют wizards и ribbon.

А если мы спустимся ниже, на уровень контролов/виджетов – в чем ты видишь разницу между Web 2.0 и десктоп-приложениями?
Собственно widgets тоже стремятся к общему знаменателю. Web2 наборы widgets стремятся воспроизвести desktop и desktop наборы расширяются в сторону compоund web alike widgets.

Назови пожалуйста три основные технологии, на которых, на твой взгляд, основаны интерфейсы Web 2.0 приложений? Desktop-приложений?
Три основные технологии, на которых основаны интерфейсы Web 2.0 приложений:
1) AJAX (как lightweight способ посылки сообщений UI <-> модель данных – классическая фича десктоп приложений)

2) HTML/CSS как технология – склейка финального UI из компонент в единое целое. За этим много стоит на самом деле. Технология PHP/ASP и пр. как способ сборки UI. Это то, чего в desktop не было.

3) Ну и script и HTML event propagation schema, как способ функциональной связки разнородных элементов между собой. На самом деле такого в desktop UI (типизированные языки) не было.

АС: DOM еще забыли.
АФ: Да, DOM – это отдельная песня тоже.
АС: Мы с тобой одинаково смотрим на Web 2.0 с технической точки зрения, для меня Web 2.0 это – get, parse & display: получили данные (с сервера), распарсили/обработали их и отобразили.
Get – это ajax, parse – DHTML (HTML + DOM + Javascript), display – это CSS. На мой взгляд, благодаря этим вещам, мы можем теперь создавать rich user experience в Web 2.0-приложениях.
АФ: Технически и если копать до самых основ то это все как бы укладывается в парадигму CGI. Это основа образования UI в системах terminal-server. Терминалы просто становятся побогаче.
АС: Да, вот как раз в этом “просто” и заключено юзабилити и ориентация на пользователя :)

Чего не хватает на твой взгляд веб-приложениям, даже несмотря на веб-дванольность?
Немного издалека. Есть два типа пользователей в Интернет: “читатели” и “писатели”. Для читателей web 1.0 вполне себе достаточно и тех браузеров, что мы имеем – тоже. Вторая группа – “писатели” – (как role) – это те люди, которым нужна:

1. иная модель security,
2. иная модель использования (occasionally connected)
3. другие возможности взаимодействия объекты десктоп – объекты в браузере.

Например, Gmail хорош всем, за исключением того, что это – не desktop приложение :) – я хочу скачать письма и почитать их на досуге (when disconnected). Это как пример №2.

Элементарное действо: “save as” в любом word processor или e-mail клиенте. Броузер, в принципе, не позволяет ничего писать на клиенте. По соображениям security. И это – правильно для use case “читатель”.

По поводу №3: Clipboard как пример. Я хочу в свой блог вставить картинку, которую я только что нарисовал в Xara – не могу. Нужен другой клиент (UA – user agent).

Часть 2: Движок HTMLayout

Расскажи пожалуйста о библиотеке HTMLayout. Для чего она предназначена?
HTMLayout – это единственный в своем роде (на сегодняшний день) встраиваемый (embeddable) html/css engine. Встраиваемость – это принципиальный вопрос здесь:

1. Все операции, которые могут затронуть security, например, load remote resource, проходят через хост (нотификации и callback) т.е. host application управляет security policy. Это основная проблема при встраивании Gecko и Trident (IE).
2. Набор фич CSS расширен для поддержки двухмерных layout – модель html/css в web это бесконечная лента, имеющая фиксированной только ширину. В html и css 2.1 отсутствуют механизмы выравнивания содержимого по вертикали.
3. Все widgets сделаны из DOM-элементов – т.е. их компоненты стилируемы через CSS. Например, combobox это DOM-элемент и кнопка в нем (show popup) – это тоже DOM-элемент, у которого можно описать свой стиль (think of UI themes) и “повесить” некий дополнительный behavior.
4. Behaviors – как способ задания поведения конгломератов DOM элементов (a.k.a. controls). Behavior изменяет состояние DOM-элементов, а CSS это все отображает.
5. Sinking/bubbling event propagation схема, как простой и эффективный способ обработки событий.
6. Поддержка OS-themes как способ уважать предпочтения пользователя.

HTMLayout – это, грубо говоря, веб-браузер, который Windows-программист может встроить в свою программу и, таким образом, построить интерфейс программы на базе DHTML?

Можно сказать и так. Если грубо :)

Насколько я знаю, Motorolla использет его именно так. Они сделали специализированный intranet-browser на основе HTMLayout.

При этом вместо javascript для вывода и обработки виджетов (ака контролов) используется С++/C#?
Да, как способ описания действий используется язык, на котором написано host application. Есть имплементации на C++, C# , Ruby, Lua. Представь себе, что у тебя есть способ, скажем, расширять Mozilla различными UI элементами, нужными твоему приложению (<input> <widget> и т.д.).

Я подозреваю, что JS тебе не нужен будет в 95% случаев. Если у тебя есть нужный тебе набор компонент.

В windows-приложения, построенных на основе MFC/WTL, всегда были проблемы с ресайзингом – вручную приходилось масштабировать размеры контролов.

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

Решена ли эта проблема в HTMLayout? Какие средства есть в библиотеке для упрощения процедуры ресайза?
По поводу resize. Есть две проблемы: имплементация резинового layout – это да, решено и я думаю, такой гибкости нет ни в одном UI toolkit.

По поводу “конгруэнтого масштабирования UI” – потребность в этом, я думаю, не сильно велика.

“При ресайзе окна браузера изменялся размер контролов” – это можно сделать в HTMLayout, если нужно. Но, как правило, люди распахивают окно для увеличения рабочей области, а не для увеличения, скажем, размера шрифта.

Пример из немного другой оперы. В Symantec NIS (Norton Internet Security) есть поддержка high contrast mode. C помощью сугубо CSS:

@media scrren
{

и

@media high-contrast {
… css declarations…
}

Т.е. для поддержки accessibility не требуется перепрограммировать host application.

По поводу компонент в HTMLayout. Насколько я понимаю, в отличие от веба, где я работаю не с контролом, а с html-сниппетом контрола, в HTMLayout я заранее могу создать контрол, как-то его назвать и далее на этапе выполнения моего приложения – менять его состояние в зависимости от текущего события и данных?
Ты можешь написать в CSS:
input[ type="something" ] { behavior: some-behavior; }
а в HTML использовать
<input type=”something” />

Host application (твое приложение) должно предоставить имплементацию behavior, которая может делать что угодно – например создать вложенное DOM-tree и обрабатывать события от него. Один и тот же behavior может использоваться с разными стилевыми схемами образуя “визуально”-разные элементы контроля.

Собственно все input elements в HTMLayout так и сделаны – это просто набор behaviors, которые назначаются через master CSS разным DOM элементам.

Встроенные behaviors можно reuse:
<span class=myradio name=n1 /> <span class=myradio name=n1 /> <span class=myradio name=n1 />
+ css
{
span.myradio {
behavior: radio;
}
span.myradio:checked
{
background-image:….;
}

}
Соответственно, можно склеивать из простых кубиков сложные конструкции.

АС: То есть в данном случае, когда пользователь кликнет по радио-буттону, появиться фоновая картинка.
АФ: Да.
АС: И кроме того, вместо вывода простой радиокнопки, я могу вывести что-угодно? (не могу придумать пример что я могу там вывести :) )
АФ: Tabs как элемент контроля – это фактически набор radio buttons (закладки) плюс механизм binding этой группы на visibility набора панелей. Т.е. достаточно написать behavior, который, получив извещение BUTTON_CLICK от такой radio кнопки, поставит, скажем, атрибут current у соответствующей div-панели.

В CSS останется написать:

div.tab-panel { display:none; }
div.tab-panel[current] { display:block; }

Таких behavior patterns не так уж и много в живом приложении. Т.е. из простого образуется сложное. При этом CSS используется как клей, соединяющий состяние и представление в одно целое.
АС: Спасибо за детальный пример! Я-то изначально подумал ошибочно, что вместо behavior: radio; можно написать behavior: “что-то” и вместо радиокнопки в спане мы получим “что-то”, а тут скорее речь идет об изменении свойств объектов.
АФ: Да, основная задача behavior – это изменение атрибутов и состояния DOM-элементов в ответ на действия пользователя. В событии attach behavior может создать/изменить структуру DOM элемента (или его окружения), если это нужно конечно.
АС: То есть behavior позволяет

1. Сформировать код для контрола.
2. Управлять состоянием контрола.

АФ: Можно и так, и так. Иногда, например, требуется написать так:
input[type=radio] { behavior: radio my-something; }
т.е. каскад behaviors.

Приведи, пожалуйста, примеры приложений, которые используют HTMLayout?
Из тех, что на слуху – Symantec (Norton Antivirus, Norton NIS, Norton 360).

Все игрушки Alawar – там у них консоль есть, в которой используется HTMLayout:



Часть 3: Тенденции развития UI

Каковы сейчас, на твой взгляд, тенденции развития UI в десктопных приложениях?
Software vendors стремятся перейти на модель сервисов – т.е. пользователь платит за сервис регулярно, а не один раз. А вообще UI UIю рознь. Есть типичные desktop productive utilities, а есть, как я уже говорил, приложения большой красной кнопки.

Я бы не стал выделять здесь mainstream. Это вредно, к тому же как там у Кузьмы Пруткова: “Не всякому человеку даже гусарский мундир к лицу”.

А если посмотреть на прогресс в области контролов и средств разработки интерфейса? Он есть на твой взлгяд? Видишь ли ты какие-либо тенденции?
Есть тенденции стилистические и есть технологические.

Стилистические – “пиктографичность UI” и “гиперлинковость”.
Технологические – declarative UI – неизбывная мечта человечества.

Раньше, когда я занимался программированием, я разрабатывал интерфейсы при помощи редактора ресурсов Visual Studio. На разработку интерфейса у меня уходило очень много времени. Однаком и сейчас проектировщик интерфейса для UI должен учитывать сложность разработки UI программистом.
С точки зрения разработки я думаю, что ни одна из технологий не представляет какого-либо значительного преимущества в скорости создания “морды лица баз данных”. У VB можно быстро “накидать” форму в редакторе. Но дальше уже начинаются пляски с бубном. Как вклеивать формы одну в другую, как обрабатывать события в сложных конструкциях и т.д.

Веб, имхо, ушел здесь вперед – интерфейс удалось практически полностью отделить от бизнес-логики при помощи шаблонов и шаблонизаторов. В десктопе, насколько я знаю, дела обстоит намного хуже.
Да, и это тоже тендениция – шаблоны, генерация UI, CSS как сущность (стилирование существующего DOM). VB и MFC не расчитаны на стилирование элементов и сборку сложных конструкций из простых.

АС: Да, чтобы изменить стиль интерфейса и в VB и в MFC придется попотеть, чтобы обойти все properties и изменить свойства стиля. А в MFC еще и перекомпилировать придется проект. Чтобы разработать свой контрол, так вообще придется изучать ActiveX/COM технологии.

На мой взгляд, HTMLayout – это значительный шаг вперед в разделении внешнего вида приложения от его бизнес-логики. Дизайнер интерфейса (проектировщик) может разработать прототип в той же Axure (которая изначально заточена под web-приложения) и далее реализовать HTML-код, оформив его в виде шаблона, с которым уже дальше может работать программист (добавляя behaviors, переменные и прочее в шаблон).

HTMLayout, на мой взгляд, интегрирует преимущества “настольности” и веб-технологий.

АФ: В принципе да. К тому же какие-то свойства в VB и в MFC изменить в принципе невозможно. HTMLayout-интерфейс – это другой уровень возможностей.

Резиновость layout, например. Жесткий layout форм это то, что мешает масштабируемости UI. Controls в Windows диалогах, как правило, жестко приколочены к подложке. Ставим скажем 120dpi на экране и все – UI не читаем.

За резиновостью стоит еще accessibility – не все пользователи могут использовать UI на стандартных 96dpi.

HTMLayout способствует промышленной разработке софта – UI и логика становятся “слабо связанными”, т.е. возможно разделение на команды – UI дизайнеры и стилисты и люди backend, делающие логику.

Части 4 и 5
Мне кажется разумным оставить эти части для следующей статьи – уж слишком много букв получается, даже для блога Guicci :)

Что будет в следующей статье:

• Эстетика ПО и веб-приложений.
• MS Expression, XAML, Aurora.
• Анимация в HTMLayout.

Полезные ссылки

• Сайт компании Terra Informatica
• Библиотека HTMLayout
• Демонстрация возможностей библиотеки (demo applications). Инструкция:
  1. Скачайте архив.
  2. Распакуйте.
  3. Запустите bin/browse.exe.
  4. Кликните меню File/Open… и загружайте HTML-файлы из каталога html_samples/.
  5. Изучайте возможности движка на примерах.
• Форум на RSDN, посвященный обсуждению движка HTMLayout (автор библиотеки лично отвечает на вопросы пользователей в форуме, кроме этого там обитает множество энтузиастов, которые занимаются портированием HTMLayout’а под другие языки – Python, C#).
• Основы работы с HTMLayout (start-up guide на русском языке).
• 
• 
• 
• 
 Понравилась заметка? Подписывайся на обновления блога!
           

      ЖЖ  E-mail  RSS