How I would do that Start Page.

Start Page in HTMLayoutTwo days ago I have downloaded and installed new Microsoft Visual C++ 2008 Express.

First thing that you see when you start its IDE is the Start Page (close to what you see on the right). I was intrigued how this view is made. That clearly have look and feel of a web page. Some portions of data are coming from Internet.

So I took the Spy++ application and pointed it on the view. It was a surprise for me to discover that this view is made of separate windows in old VB style. It is made of 40 (forty) child windows. That is not so good to be honest:

  • too resource greedy, e.g. without this view IDE takes 10 Mb less of memory;
  • and as you might expect scales badly on high DPI settings, see example of actual rendering:
  • VS on Large DPI

Thus I’ve decided to reproduce this screen in HTMLayout. Here are steps of how I’ve made it.

1. Images

For this particular view we need 4 ( and only four ) images:

  • Header – header background;
  • Body back background of the body section;
  • Panel back background and borders of informational panel;
  • Panel caption background – background of panel’s caption.

(I took these images from screenshot I made from Microsoft Visual Studio window. These images are probably copyrighted. In any case my respect to their authors.)

Ok, back to business…

2. HTML

Structure of HTML for such a view is simple:

<body>
  <div .header />
  <div #sidebar >
    <div .panel #recent-projects><caption>Recent projects</caption>
      <ul><include src="content/list-of-projects.htm" /></ul>
      <table>
        <tr><td>Open:</td><td href="#">Project...</td></tr>
         <tr><td>Create:</td><td href="#">Project...</td></tr>
      </table>
    </div>
    <div .panel #getting-started><caption>Getting started</caption>
      <ul><include src="content/getting-started.htm" /></ul>
    </div>
    <div .panel #headlines><caption>Headlines</caption>
      <dl><include src="content/headlines.htm" /></dl>
    </div>
  </div>
  <div .panel #msdn-news>
    <caption>MSDN: Recent news</caption>
    <dl><include src="content/msdn-recent-news.htm" /></dl>
    <p style="text-align:right;"><a href="#">More news...</a></p>
  </div>
</body>

Nothing spectacular so far I would say.

Note:

Markup above is HTMLayout specific: 1) <div .panel > is a short form of <div class=”panel” > and
<div #recent-projects > is <div id=”recent-projects” > and you can use both forms. And 2) <include src=”content/list-of-projects.htm” /> is so called client side include instruction – it allows to assemble final HTML from different source files. This include makes sense here as while parsing engine will generate HLN_LOAD_DATA notifications for each inclusion. These portions are dynamic so handling this notification we can generate HTML content fragments we need. That is close to the CGI idea.

3. Styles

Final piece left – styles. That is really simple as HTMLayout supports expandable backgrounds.
If you have read document under the link above then you should get the idea of this fragment. It defines styles for our panel and its caption:

    div.panel
    {
      background-image: url(images/panel-back.png);
      background-repeat: expand; 
      background-position: 14px 14px 14px 14px; 
          // top right bottom left offsets/margins
      padding: 0 10px 10px 10px;
      margin-bottom:20px;
    }

    div.panel > caption
    {
      background-image: url(images/panel-caption-back.png);
      background-repeat: expand stretch-left stretch-middle stretch-right; 
      background-position: 3px 3px 3px 3px; 
         // top right bottom left offsets/margins
      padding:6px 6px;
      color:white;
      font-weight:bold;
      position:relative;
      top:-0.7em;
      margin-bottom:-0.6em;
    }

Other styles are also simple as these two above.

To see this mock-up alive you can download demo browser.exe with samples and run /bin/browse.exe. Click open button and find /html_samples/MSVS-start-page/start-page.htm. This is it.

4. Epilogue

It took me one hour to design this sample (from the set of existing images).

Loaded document consumes 5 (five) times less resources than original solution.

And HTMLayout is free. For Microsoft Visual Studio Team (respect!) too 🙂

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:


Norton 360

Norton AntiVirus

Alawar Game Box

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.

Name some main differences between today’s desktop applications and Web 2.0 applications?


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.

AS (Alexander Sergeev): By the way, Don Norman introduced a concept called affordance – analogous to being self-descriptive. For example, scissors – it’s obvious that the fingers go into the holes 🙂


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.

If we go down to the level of controls and widgets – what do you see as the main difference between desktop and Web 2.0 applications?


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.

So, roughly speaking, HTMLayout is a web browser, which a Windows programmer can embed into his or her program, and base its UI on DHTML?


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.

C++ and C# is used instead of Javascript to display and process widgets (aka controls)?


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.

Regarding components in HTMLayout. As far as I understand, on the web, I am working not with the control itself but rather with the control’s HTML-snippet. In HTMLayout, I can create the control beforehand, name and change it at the execution stage, depending on the current event and data?


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.

AS: I.e. in such a case, when the user clicks a radio button, the background image could appear.


AF: Yes.

AS: Besides, instead of outputting a simple radio button, I can show anything? (can’t think of an example of what else I could output 🙂 )


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


What do you think some of the current developing tendencies for UI on the desktop?


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

JavaScript functions, named parameters.

JavaScript does not support named parameters. For example following will not work in JS:

  var something = foo( one: 1, two: "2" );

As a workaround people use functions that accept single parameter – object reference:

  var something = foo( { one: 1, two: "2" } );

but I think such notation is not good aesthetically speaking …

Problem is that classic JS supports only one form of function call :

  ref '(' list-of-values ')'

In TIScript/Sciter I decided to “fix” this by introducing second form of function call – call of function with passing object literal:

  ref object-literal

Where object-literal is a standard (for JS) object literal: '{' list-of-name-value-pairs '}'.

Thus example above can be rewritten as

  var something = foo { one: 1, two: 2 };

foo is a function here that accepts single parameter – parameter-object:

  function foo( prm ) { return prm.one + prm.two; }

Practical example:
When I need to create DOM object dynamically I can write now something like this:

          tab = Element.create { tag: "option", text: label, value: filename };

that is a bit shorter than:

          tab = new Element("option");
          tab.text = label;
          tab.attributes["value"] = filename;

To be able to create DOM elements this way I’ve extended Element class (DOM element in Sciter) by following function:

/*
  create element by definition (def)
  Example:

  var el = Element.create { 
    tag:"p", 
    text:"hello", class:"info", id:"id1" 
  };
*/
function Element.create(def)
{
  var tag = def.tag; if(!tag) throw "No tag given!";
  var text = def.text || ""; 
  var el = new Element(tag, text);
  for (var k in def)
  {
    if( k == #tag || k == #text ) continue;
    if( k == #children )
    {
      var children = def.children;
      if( typeof children != #array) throw "'children' is not an array!";
      for (var c in children )
        el.insert( Element.create(c) );
      continue;
    }
    // others are just attributes
    el.attributes[k] = def[k];
  }
  return el;
}

and this is it.