fortes.com

I went to Adobe’s OnAir Seattle yesterday, which was a really interesting event that I’d recommend attending if you have the time. Unfortunately, I had to leave before the end of the day, but here’s a summary of the notes I took while I was there.

The Big Picture

Adobe’s goal is to let web developers can use their existing skills (HTML, CSS, JavaScript, Flash, and Flex) to create desktop applications. AIR (formerly Apollo) provides cross-platform installation and application updates, a local database, and a variety of new APIs for managing local resources (local file access, controlling window chrome, drag and drop, etc). The Adobe guys were clear that this isn’t about porting existing web sites onto the desktop — assets and web services will obviously be re-used, but the emphasis was on not needing to learn new technologies (just a few new APIs).

Interesting Tidbits / Nerdy Technical Details

• Installation: Applications are installed via a single .air file. Installed applications can be removed just like normal applications (i.e. via Add/Remove Programs on Windows, or by throwing the application in the trash on the Mac). An express install (which can bootstrap the AIR runtime) and detection is also possible via Flash.
• Application Updates: AIR will provide support for automatic application update checking and upgrading.
• HTML Rendering: Adobe chose the WebKit HTML engine (used by Safari and Konqueror) specifically because of it’s size and speed. Someone asked if they were considering moving to Firefox at some point, and they were clear that Firefox just couldn’t meet their size requirements for mobile.This cements WebKit’s position as the number three browser family (sorry Opera).
• PDF Support: Requires Adobe Reader 8.1 — unlike HTML and Flash support, the Adobe Reader must be installed separately (I’m not sure what happens if it’s not installed).
• HTML / Flash Integration: It looks like Adobe’s done a good job integrating the two — you can make script calls between the two, and there don’t appear to be any visual differences between the technologies. I’m not sure about PDF though, I’ll need to look into that.
• Script Engine: They’re using the Tamarin JavaScript engine, which is far faster than what’s in browsers today. They showed a demo of BuzzWord, a word-processing program built on Flash, which implements their own line layout and pagination APIs that run pretty fast thanks to the JS engine. The Mozilla team plans to use Tamarin in Firefox version 4.0.
• SQLite: This must be fairly new, because none of the talks or demos I saw were using the local database. Adobe did mention that they’re working with Google to make sure they’re API-compatible with Google Gears, which also uses SQLite.
• Native Windows: Can create native windows, or go chrome-less windows with transparency that give full-freedom (at the potential cost of consistency with other applications on that OS).
• Plugin Support: Currently only Flash and PDF can be embedded within HTML. Adobe says they’re open to feedback as far as other plugins (QuickTime was requested by a member of the audience).
• SDK and Tools: Adobe already has mature tools with the Flash authoring environment, Flex builder, and Dreamweaver. They making sure to adding support for creating AIR packages (which are ZIP files) in their existing products, lowering the learning curve for developers. Command-line tools for packaging AIR files are provided as well.
• Adoption Rates: Adobe made sure to mention how quickly new versions of Flash get adopted by users — they get 85% penetration within 9 months, which is quite impressive. Obviously, it’s unclear if AIR could get this
• Linux Support: Planned in late 2008. Adobe says they’ve been waiting for the latest version of Flash for Linux before they port AIR.
• Random Notes: Built-in support for associating file types at install time, don’t need admin rights to install AIR or AIR applications, events for regaining network connection, file dialogs, drag and drop support, use PNGs instead of dealing with .ico files, and Creative Commons licensing for the books.

MS vs. Adobe: My Take

This is the right strategic move for Adobe. They’ve managed to attack the biggest weaknesses of their chief competition, Microsoft’s WPF, by being cross-platform and leveraging existing technologies already used by web developers. Using existing technologies also means there are many mature tools for both designers and developers coding in HTML/Flash, which is not the case with WPF. Adobe made a good choice not trying to boil the ocean with a lot of new technology.

Granted, WPF’s target market is a bit different than AIR’s (there are a large number of WinForms developers already using .NET technologies), but for web developers the learning curve and lack of cross-platform support made WPF a non-starter (notice how much more interest Silverlight has recieved in the community). Obviously, there are still many areas where WPF is superior (3D and document layout, to name two), but I think AIR’s advantages more than make up for these drawbacks (from a web developer’s point of view).

Although still in it’s infancy, Silverlight will likely become the real competitor to AIR. Although it’s feature-poor in comparison to Flash, Microsoft’s clearly devoting a lot of resources to catching up quickly (notice the simultaneous release of 1.0 beta and 1.1 alpha — which surely required a lot of testing resources). Silverlight plays nicely with HTML and JavaScript, provides good language support (including trendy languages like Ruby and Python), and has a very fast script runtime as well. It already lets you go into full-screen, I don’t think adding more windowing APIs wouldn’t be a stretch. I fully expect Microsoft to move in this direction.

Obvious Disclaimer: I do not work for Microsoft (although I used to). I don’t have any inside information. Don’t take blog posts too seriously, especially ones typed hurriedly on a hot day.

While reading an article in today’s New York Times, I saw the following sleazy ad:

How tall is Paris?

Answer correctly to receive your Pink Laptop

You’ve probably seen this genre of ad before, which offers free merchandise for a trivial task — of course, the ads always state that “Details Apply” in tiny text (I wonder how the FTC feels about these “details”).

As stupid as these ads are, they’re not much worse than the advertisements for escort services that you see in back pages of a free weeky — but you’d never see one of those next to a top story in the print edition of the New York Times!

Why not? Money, of course. A prominent ad in the print edition of the NYT is far too expensive to be purchased by the low-class advertisers — and even if it were cheap enough, the NYT’s higher-end advertisers (luxury companies such as Tiffany’s, who spend a lot of money to consistently advertise in the paper) would never allow their brand to be anywhere near an ad like that.

But it turns out that Tiffany’s and other high-end advertisers don’t advertise on the web — because there’s no appropriate online advertising surface out there for them. This missing business causes two side-effects:

1. The scummy advertisers aren’t priced out of the market
2. The Times, faced with low-revenues in their online edition, can’t be as choosy when it comes to advertisers

Broader Markets are Good

One could mis-interpret my previous statements and say that I’m an advertiser snob, looking to price out the little guy. This, of course, is false. Even with way less than ten percent of the advertising market, the Internet has brought more advertisers into the market — this is undoubtedly a good thing.

Large publishers, like the Times, can (and should) still cater to the little guy. Unlike the print version, an online edition need not display the same advertisement for all readers in perpetuity. A digital publication can sell limited run, or niche-targeted advertisements at a lower total cost and higher visibility than they could in the one-size-fits-all print edition. In fact, I’m certain they already do so.

Publishers like the Times have to start being picky and demanding a certain level of quality from their advertisers. In the print world, it’s clear that advertisements are part of the content (look at any fashion magazine if you’re in doubt) — this attitude needs to extend to the digital realm.

Moving toward a better future

At Mix, I showed some sketches of what online Magazines can become. Roger Black and I are working to create higher-end content experiences that won’t dilute the brand of luxury advertisers. Rest assured, you won’t be asked to punch a monkey.

It’s still early, so all I have to show are sketches — but there’s a lot of room for improvement in this space! I’m a bit surprised by the state we’re in today, because so many of today’s mistakes come from ignoring the lessons learned during decades of print publishing. Of course, digital is a different medium than print, which means that we need new plenty of new paradigms in order to succeed — but that just makes it all the more exciting!

Update: Other Voices

After writing this post, I found P.J. Onori’s excellent (and similarly-titled) article The Sorry State of Online Advertising — which I recommend. He makes similar points (and posted them first, so he wins):

I would argue that the sheer number of advertisements some of these sites have on their site is evidence that the current ad model is not working. Instead of thinking of more original, symbiotic and user-friendly forms of advertising, most site creators have subscribed to the “more ads means more revenue” philosophy. This current relationship between the site creator and advertisers is much like a building landlord and a renter. Space is offered to the advertiser and other than the exchange of money, there is little to no relationship between the two. Under this model, the landlord attempts to rent out all the space to whoever offers money. The problem with this model is that if the landlord just rents out rooms to anyone without any discernment, the landlord’s property could be quickly destroyed by the renters. Meanwhile, the apartment building is in shambles and no one is interested to look at the space, much less rent it. Similarly, if a website does not carefully choose its advertisers, the web site could shortly be a ghost town. An interest in short-term gains can ultimately disenfranchise a site’s users to the point that they do not come back. Guess what, advertisers are going to drop you like a bad habit once you are not giving them what they want - click-throughs and revenue.

Another article worth reading is The Devil & Online Advertising by Darius A Monsef IV. Here’s an excerpt:

Do you know why you only see those terrible, low-budget ads on your local television stations? Because it costs too much for those guys to hock their “Super-Mega-One-Day-Only-Sales-Extravaganza!” on national television. When the price point to advertise online is in the pennies per CPM, then you’re going to end up with low-quality advertisers.

Microsoft has posted videos from the Mix sessions, which means you can view the video of our panel online. There’s also a WMV version you can download directly (roughly 80 MB).

Unfortunately, the production quality of the video isn’t very good. The video shows only the projection feed, which was fairly static except for about 25 minutes worth of demos by myself and Tom Bodkin. Also, the projector in the room was running at 1280 by 720 pixels, which was then (stupidly) stretched to a different aspect ratio for the video. I’ve included a few non-stretched screenshots from my demo below:

If you don’t feel like watching the video, Tim Anderson has written a good summary of the panel.

During the session, I showed a demo that myself and Roger Black (amongst others) have been working on in the past couple of weeks. It’s a rendition of the English-language version of Reporte Indigo, a Mexican online weekly magazine currently done in Flash. Our goal was to show some of the directions we see online reading experiences moving toward: richer, branded layouts that look good across a variety of screen dimensions, integrated media, richer advertisements, and continued increases in community-driven features. My big fat mouth has more to say about this area, but that will have to wait until another post.

Unlike Inline elements, Block elements take up the entire width of the text column and have line breaks before and after their content. By far, the most common block element is Paragraph.

Here are the elements that shipped with WPF that derive from Block:

• Paragraph: With a straightforward name, this element (along with TextBlock) is the only container for Inline elements.
• Section: A container for other Block elements — analogous to Span, which contains Inline elements.
• BlockUIContainer: A container for UIElement-derived classes to be displayed as a block. Analogous to InlineUIElement.
• List: Creates an ordered or unordered list. Contains ListItem elements.
• Table: Contains TableRowGroup

elements.

Additionally, there are a few helper classes that are a bit block-ish:

• ListItem: Block container for use within a List.
• TableRowGroup: Container for TableRow objects.
• TableRow: Container for TableCell objects.
• TableCell: Block container for use within a TableRow.

Just like the inline elements, all of these elements do not derive from UIElement or Visual — this is because they do not have a one-to-one mapping between their content and visuals on screen. The reasons for this, and their ramifications, will have to wait for the next post.

Differences from HTML

• No nested paragraphs: It’s worth re-iterating, because you’ll probably run into it some time.
• Strict structure for Lists and Tables: WPF is strict about the structure of Lists and, in particular, Tables. This leads to verbose markup.
• Only one List: Unlike HTML, there are no specialized elements for ordered and unordered list. You use the MarkerStyle property.

The term inline may be familiar if you know HTML and CSS — an inline element is displayed within an existing flow of text, positioned on lines of text shared with other inline elements.

Let’s make this more clear with a screenshot and a bit of code:

<Border xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" HorizontalAlignment="Center" VerticalAlignment="Center" BorderThickness="1" BorderBrush="#ccc" Padding="10">
  <TextBlock TextAlignment="Left" TextWrapping="Wrap" Width="400" FontSize="25" FontFamily="Candara">
    <Bold>Of Montreal:</Bold>
    <Hyperlink Background="#cef">Hissing Fauna, Are You The Destroyer?</Hyperlink>
    <Italic>(2007)</Italic>
  </TextBlock>
</Border>

In our example, we are using three inline elements: Bold, Hyperlink, and Italic. Each of these shares space on a line within our TextBlock (you can think of it as a paragraph). I added a background to the Hyperlink element to emphasize the fact that the element is broken across a line.

Here are all the elements shipped with WPF that derive from Inline (you can, of course, subclass and add your own):

• Run: A string of text.
• Span: A container for grouping other Inline elements. Its subclasses provide default formatting, and linking:
  • Bold
  • Italic
  • Underline
  • Hyperlink
• LineBreak: Forces a hard line break within a text flow. Provided as a markup convenience (newline characters are honored if used within code).
• InlineUIContainer: A container for UIElement-derived classes within text.
• AnchoredBlock: I’ll cover these in detail later, but note that these cannot be used within a TextBlock
  • Floater
  • Figure

As I’ve mentioned before, it’s rarely necessary to explicitly use Run when writing markup (although it’s important when writing code). The same mechanism is used with InlineUIContainer for convenience.

Span and its subclasses are straightforward for those with experience with HTML, as is LineBreak.

Figure and Floater don’t have direct analogues in HTML, but the functionality is similar to the CSS property float. More on these later.

Differences from HTML

If you’re already familiar with HTML/CSS, then the concepts in this entry are old news to you. For easy skim-reading, here are the major differences between WPF XAML markup and HTML markup for inline elements:

• No semantic classes: This is a subtle, but important, point — the markup classes exposed in WPF have no semantics, they are presentational only.
• Once an Inline, always an Inline: This is partially a consequence of the previous point, but unlike CSS, you cannot change the display-type of an element — i.e. you can’t change an element from inline to block, or vice-versa. If you want to do that, you must change the elements used and the tree structure.
• Can’t nest paragraphs: The content model is strict, so you can’t directly put a block element within a Paragraph (we’ll learn how to do this via InlineUIContainer or an AnchoredBlock in later posts).
• Invisible container elements: Run and InlineUIContainer may not be in the markup, but they’re there if you walk the tree.

Next, we’ll look at the properties you can apply to inline elements.

A useful feature that was left out of the first version of WPF is the ability to databind the value of Run.Text. I was still around when this feature was (unfortunately) cut — but don’t despair! It’s not actually that hard to write yourself.

We’ll do this by creating a subclass of Run, which I’ve creatively named BindableRun.

using System;
using System.Windows;
using System.Windows.Documents;
 
namespace BindableText
{
  /// <summary>
  /// A subclass of the Run element that exposes a DependencyProperty property 
  /// to allow data binding.
  /// </summary>
  public class BindableRun : Run
  {
    public static readonly DependencyProperty BoundTextProperty = DependencyProperty.Register("BoundText", typeof(string), typeof(BindableRun), new PropertyMetadata(new PropertyChangedCallback(BindableRun.onBoundTextChanged)));
 
    private static void onBoundTextChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
      ((Run) d).Text = (string) e.NewValue;
    }
 
    public String BoundText
 
      get { return (string)GetValue(BoundTextProperty); }
      set { SetValue(BoundTextProperty, value); }
    }
  }
}

The code is pretty straightforward, we create a new DependencyProperty in the usual manner. Then we add a PropertyChangedCallback that manually sets the Text property. That’s it! We rely on the base class to take care of everything else.

You can use this in DLL, by declaring an XML namespace and linking it to a CLR namespace, as in the example below:

<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:bt="clr-namespace:BindableText;assembly=BindableText">
  <FlowDocumentScrollViewer>
    <FlowDocument>
      <Paragraph>
        You can control the value of this text through the TextBox below: <bt:BindableRun FontWeight="Bold" BoundText="{Binding ElementName=tb, Path=Text}" />
      </Paragraph>
      <BlockUIContainer>
        <TextBox Name="tb" Text="This is text with spaces that wraps across a line … like this!"/>
      </BlockUIContainer>
    </FlowDocument>
  </FlowDocumentScrollViewer>
</Page>

If you’re running this in XamlPad, you’ll have to make sure that the BindableRun.dll file is in the same directory as XamlPad itself. You can do this by either creating a new copy of XamlPad.exe or copying the BindableRun.dll into the directory where you keep XamlPad (C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin in my case).

If you want to download this class, I’ve created a project (with the DLL) that you can download and use: BindableText.zip (13 KB).

Update 3/21: Paul Stovell mentions an alternate technique that creates an attached property instead of a subclass to achieve the same effect.