Talks about HTMLayout

Here is a translation of the interview in Russian I gave to Alexander Sergeev from the HumanoIT.

Alexander Sergeev(AS) says:

My long time dream – to write a shareware program and sell it through the Internet: cash out, Brazil, Maldives, Tokyo, beaches, skiing, casinos… ahhh. This summer I almost brought it to reality… all thanks to one wonderful graphical engine. I’ll tell you right away – I didn’t finish my program yet (simple lack of time), but the summer has not gone wasted – now I know, WHAT interfaces can be developed on the desktop. For us (in HumanoIT Group) this knowledge is equivalent to its weight in gold, since we don’t develop interfaces for the web only.

HTMLayout is currently the only embeddable HTML/CSS engine of this type.

Here are a couple of interfaces based on the HTMLayout engine:

Nobody can tell us about HTMLayout better than its author. Hence, I present to you an interview with Andrew Fedoniouk, the author of this wonderful graphical engine.

Part 1: Ponderings about Web 2.0

What do you think about Web 2.0: what is the essence of Web 2.0 for you as a user? As a programmer?

Andrew Fedoniouk(AF): First of all, nobody knows for sure what Web 2.0 is 🙂 It’s a set of technologies and solutions at the level of a "hack" – this I will tell you. For myself, I classify Web 2.0 as a set of technologies which supports Occasionally Connected Web Applications.

Please clarify what you mean by Occasionally Connected Web Applications?

It’s an application, which has a built-in capability of working offline. I.e. Web 2.0 is more about desktop applications, than about the actual web. It’s about using web on the desktop and vice versa – giving web applications a desktop-like feeling.

Storage of data. Actually – this is the age old difference between client-server and desktop applications. Web 2.0 tries to bring the "comfort" of desktop to the web.

What do you think the main differences in UI between the two are? (let’s leave HTMLayout out of the picture for now)

Inductive UI versus Productive UI. Traditionally, Web applications are ossasionally used applications. I.e. web application’s UI must be self-descriptive: any user off the street should be able to do what he needs to, without reading any docs.
Let’s take Norton Antivirus and Norton Internet Security as examples. These are applications of a "big red button" – rarely accessed (by UI), so their UI must be intuitive. This is one of the reasons Symantec uses HTMLayout in their products.

Another example is a media player application. That kind of applications are built around "Play" button. I cannot imagine anyone reading manual of, say, WinAmp.

What do you see as inductive UI? Wizards, oriented to perform user tasks?

Yes, inductive UI is a paradigm of "steps" (a wizard) – enter some data, press submit, move to the next step.

AF (Andrew Fedoniouk): Sure.

And what do you mean by productive UI?

Inductive UI is Web 1.0. Web 2.0 – is (among other things) an attemp to make productive UI available in the web. Productive UI refers to applications used every day. A characteristic feature of such applications is an attempt to minimize the amount of efforts to achieve a desired result. Shortcuts, for example, are an obvious attribute of a productive UI. Toolbars, among other things, are as well.
But this distinction between Inductive and Productive UIs is becoming less clear. The complexity of applications is growing, so even such apps as MS Word use wizards and ribbon.

Widgets are also approaching a common denominator. Web 2.0 widget kits are striving to recreate the desktop, while desktop kits are going in the direction of compound web alike widgets.

Please name three main technologies, which you think are the basis of Web 2.0 applications? Desktop applications?

1. AJAX (as a lightweight way of sending messages between the UI and the data model – a classic feature of desktop applications)


2. HTML/CSS as a technology for gluing together the pieces into a final UI. There is actually a lot behind this. PHP/ASP/etc technologies as a way of putting together the UI. This is what the desktop didn’t have.


3. Finally, scripting and HTML event propagation schema, as a way of connecting different elements between each other. In fact, this was not present in the desktop UI (typed languages).

AS: You forgot about DOM.

AF: Yes, DOM is a whole different aspect.

AS: We see Web 2.0 eye to eye from the technical perspective. For me, Web 2.0 is get, parse & display: get the data (from the server), parse/process the data and display it. Get is ajax, parse is DHTML (HTML + DOM + Javascript), display is CSS. I think that it is thanks to these technologies that we now can create rich user experience in Web 2.0 applications.

AF: Technically, if we dig deeper, this all falls under the paradigm of CGI. This is the basis of generating UI in server-terminal type systems. Terminals are just becoming more resource rich.

AS: Yes, the last point sums up the need for usability and user-orientated UI’s 🙂

What do you think web applications lack, even disregarding web-duality?

Starting from afar, there are 2 types of Internet users: "readers" and "writers". For readers, Web 1.0 is quite sufficient, and so are the current browsers. The second group – "writers" – are the people who need a different:

1. model of security


2. usage model (occasionally connected)


3. capability for interaction between desktops objects and browser objects

For example, Gmail is great at everything (as that Exchange Web Client – web client of “big” Outlook), except for the fact that it’s not a desktop application 🙂 I want to be able to download email and read it when I have free time, while disconnected. This is an example #2.

The simple action "save as" in any word processor or email client. In fact, the browser disallows writing anything on the client due to security concerns. This is the right way for the "reader" use case.

About #3, let’s use the clipboard as an example. I want to insert an image I just drew in Xara into a blog entry and it’s not possible. I need some other client ( UA user agent) to accomplish that.

Part 2: HTMLayout Engine

Tell me a little about the HTMLayout library. What is it for?

HTMLayout is a unique (in its own right) embeddable html/css engine. Embeddability is the focal point here.

All operations which concern security, for example load remote resource, go through the host (notification and callback). Hence, the host application is in charge of the security policy. This is the main problem while embedding Gecko and Trident (IE, IWebBrowse).

The CSS feature set is extended in HTMLayout to support 2D layout – the HTML/CSS model in the web is an endless tape, having a fixed width only. HTML and CSS 2.1 lack a method to perform vertical alignment.

All widgets are made from DOM elements – i.e. their components are styled through CSS. For example, combobox is a DOM element and the button in it (show popup) is also a DOM element. This button can have it’s own style (think of UI themes), and additional behavior associated with it as well.

Behaviors – as a way of setting behaviors per se for conglomerates of DOM elements (aka controls). Behavior changes the state of DOM elements, while CSS displays it all.

Sinking/bubbling event propagation schema, as a simple and effective way to deal with events.

Support for OS themes – as a way to respect user preferences.

You can say that. If roughly 🙂

As far as I know, people in Motorola use it exactly like that. They made a specialized browser based on HTMLayout that communicates with http server.

Yes, the language of the host application is used to describe actions. I know about various bindings of HTMLayout in C++, C#, Ruby, Lua, Python, etc.. Imagine that you had a way to, say, extend some HTML/CSS engine with various UI elements needed for your applications (<input>, <widget>, etc). I suspect that you won’t need JS in 95% of the cases if you have the required component set.

There have always been resizing issues in Windows applications based on MFC/WTL – you had to manually adjust the size of the controls.  On the web, I have never seen a "rubber" application, which would have automatically (upon browser window resize) adjusting control size (inputs, combo boxes, etc). Is this problem resolved in HTMLayout? What features are available in the library to simplify the resizing procedure.

There are two problems about resize.
The first – implementing a rubber layout – it is in HTMLayout already by the nature of HTML and CSS. I think this kind of flexibility is not available in any other UI toolkit.
The second – "congruent UI scaling" – is not that much of a problem in my eyes. "Automatic resize of controls when the browser window is resized" – this can be done in HTMLayout, if that’s what you need. However, users usually make the window bigger to increase the working area, rather than to increase, for example, the font size.

An example from a different area. Symantec NIS (Norton Internet Security) has support for high contrast mode. It’s done simply with CSS by using different media types (normal screen and high-contrast screen settings are really different media types):
@media screen { … css declarations… }
@media high-contrast { … css declarations… }

Therefore it is no need to reprogram the host application to support accessibility.

You can write in CSS:
input[ type=”something” ] { behavior: some-behavior; }
and in HTML to use it as:
<input type=”something” />

The host application should provide a behavior implementation which can do pretty much anything. For example, it could create an embedded DOM tree and handle the events it generates. The same behaviour can be used by different style schemas, creating visually different control elements.

In essence, all input elements in HTMLayout are made this way. They are simply a set of behaviors which are assigned to different DOM elements through the master CSS style sheet.

Embeddable behaviors can be reused:
<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:….; }

Furthermore, it’s possible to glue together complex structures from simple blocks.

AF: Yes.

AF: Tabs, as UI control elements, are pretty much a set of radio buttons (bookmarks) augmented with a binding mechanism to the visibility panel set. I.e. it is sufficient to write a behavior, which upon receiving a BUTTON_CLICK notification from such a radio button, could set the :cuurent state flag of some corresponding div panel.

All that remains to be done is a bit of CSS:
div.tab-panel { display:none; }
div.tab-panel:current { display:block; }

There aren’t that many behavior patters like that in real applications. I.e. creating something complicated from something simple. The CSS code is used as glue, binding together state and appearance into a single entity.

AS: Thanks for the detailed example! Originally, I mistakenly thought that instead of behavior:radio; I could write behavior:"something" and instead of the radio button we would get "something" in the span. Instead, it seems that we are changing object properties here.

AF: Yes, the main purpose of behavior is changing state attributes of DOM elements in response to user actions. In the behavior::attach() handler, it’s possible to create or change the DOM structure of the element (or its surrounding), if required.

AS: So, behavior allows to manage the contol’s state.

Please provide an example of applications which use HTMLayout?

Off the top of my head – Symantec (Norton Antivirus, Norton IS, Norton 360). All games from Alawar have a "game console", which uses HTMLayout:

Part 3: UI evolution tendencies

Software vendors are striving to switch to a service model – i.e. the user paying regularly for a service, rather than once. UI’s are very different from each other. On one hand, we have typical desktop productive utilities. On the other, we have the aforementioned big red button applications. I wouldn’t try and pick out the mainstream. This is counter-productive, since I believe there is no one fit all solution here.

What if we look at the progress in the area of controls and tools for UI development? Is there progress? Do you see any tendencies here?

I see both technical and stylistic tendencies:

Stylistic – "pictographic UI’s" and "hyperlinking"

Technologic – declaraitive UI – the unfulfillable dream of all humanity

Back when I was still coding, I created interfaces with the help of Visual Studio’s resource editor. It took me a very long time. Even today, the interface UI developer should keep in mind the complexity of the task he is giving to the UI programmer.

From a developer’s perspective, I think none of the technologies offers a noticeable improvement in the time taken to develop the bare interface without any data behind it. VB(6) allowed you to quickly throw some forms together in the editor. However, that’s where it stops. How do you create a form within another, handle events in complex structures, etc.

IMHO, the web is far more advanced in this respect – the interface is almost completely separated from the business logic with the help of templates and templators. On the desktop, as far as I know, everything is much less cheesy.

Yes, there are also tendencies – UI generation from templates, CSS as an entity (stylization of existing DOM – seperation of semantic(data,code) and style). VB and MFC simply are not made for stylizing elements and combining simple elements into complex structures.

AS: Yes, it’s not so easy to change the interface styles in VB and MFC. You have to go through all properties and change the styles in each of them. In addition, in MFC you have recompile the project as well. To develop your own control, you need to study the ActiveX/COM technologies.

For me, HTMLayout is a significant step forward in separating the UI from the application’s business logic. The interface’s designer can quickly create a prototype in something like Axure (meant for web apps). Then, he or she can write the HTML code as a template for the programmer, who can add behaviors, variables, and other stuff into this template.

In my opinoin, HTMLayout does and excellent job of integrating the advantages of both desktop and web technologies.

AF: I think so. In addition, some properties of UI components cannot be changed at all in VB and MFC. HTMLayout interace provides a whole different level of control.

Rubber layout, for example. Fixed layout format is the exact offender which prevents scalable UI’s. Controls in Windows dialogs are usually fixed dead in their tracks. Set 120dpi on the screen and it’s over – the UI is unreadable even in some Microsoft applications.

Behind the layout flexibility of a rubber interface lies accessibility – not all users can use the UI with the default 96dpi.

HTMLayout ideology helps large scale development of software – the UI and logic become loosely coupled. Hence, the separation into teams of UI designers and stylists, and backend logic programmers becomes much easier.

Parts 4 and 5

I think it’s reasonable to leave these parts for the next article – too many letters, even for this blog. 🙂

What will be in the next article:

• SW and web application aesthetics


• MS Expression, XAML, Aurora


• Animation in HTMLayout