How Google Makes The Net Suck

Some people like to compare developers to artists. When it comes to web development, some people say there's always a man behind the curtain. Whether you agree or not, there are definitely certain freedoms that web developers enjoy. As a web developer, what are the greatest limitations and obstacles in your way? Once it may have been browser quirks. Now maybe it's all those annoying users who still use IE6. However, I think the greatest obstacle to progress is Google.

Now Google would have you believe just the opposite. I do not think they are disingenuous. In a large organization, it's all too easy for different groups to have different motivations. But ask yourself this, how much money does Google from Chrome? What does Google make money from? That's easy: advertising on search. And that is what is hold us all back.

If you have endured my purple prose to this point, I will finally cut to the chase. One of the most important aspects of any web page is how its PageRank. If your web page is all about deep sea diving, where does it surface when somebody searches Google for deep sea diving? The black art of making your page get a higher PageRank has given birth to an entire cottage industry known as Search Engine Optimization (SEO.)

As a developer I have never given much thought to SEO. I always thought that SEO was about the content of the page, and web developers are not responsible for the content. We are responsible for retrieving/generating that content from all kinds of sources, as well as creating applications that are easy and intuitive for the user to interact with a meaningful way. But, if we go back to the deep sea diving example, we're not responsible for providing information about deep sea diving. Heck you are lucky if most developers even known how to swim, but I digress.

But I was wrong. SEO is not just about content. It is about structure. If you want a good PageRank, then quality content about deep sea diving will lead to other people linking to your page and that will increase your PageRank. But there are much more instantly gratifying things you can do. For example, your page should a title and it better contain the term deep sea diving. No big deal, right? The title is really just part of the template outside of the main contents of the page. Its value has little effect on anything, besides PageRank that is. However, it gets worse.

To maximize your PageRank, then immediately after your page's body tag you should have an H1 tag whose contents should contain the term deep sea diving. Oh maybe you put the phrase on the page, but you put it in a div that styled quite nicely? Not good enough. It needs to be in an H1 tag. Maybe you used some JavaScript to create the H1 tag? That is no good at all. Why? Because The All-Mighty Googlebot does not understand how the page looks to a user. It only understand basic HTML constructs. That's right, it's time to party like it's 1999.

Oh, maybe your organization hired an artist who created a killer deep sea diving logo and you load it on to the page as an image? Not good enough. If you put deep sea diving as the alt text, that will win you some bonus points from the Googlebot, but it is still dwarfed by the rewards you could receive by busting out the H1. Nothing compares to the mighty H1 tag. And don't just put that H1 tag anywhere on the page. Heck you might even get penalized for having more than one! Nope only one, and it better appear (in the HTML source code) as close to the body tag as possible.

Ok, so maybe you give in and put the catch phrase in an H1 tag. That wasn't too bad, right? Now back to your regularly scheduled hacking? Not so fast. Do you have some hierarchical information on the page? Sections, headings, menus, etc? How are you going to do those? Again you better not even think about using things like JavaScript to create them dynamically. Nope, they have got to be static on the page. Back to divs, spans (maybe a table or two), along with some oh-so-clever CSS? Forget about it. Let me introduce you to H1's other friends: H2, H3, H4, H5, H6. That's right, if you want that damn Googlebot to "understand" the hierarchy of concepts on your page, then you better put away your divs and spans.

Maybe you think that's going overboard, but it's not. Do you have a section on your deep sea diving page called "Gear" ? Then if you want to show up on a search for deep sea diving gear, you better have the term Gear wrapped in an H2 or an H3 tag.

What about RIA technologies? Again, if you dynamically create things with JavaScript, it will get picked up, but it is non-optimal. You have to do things the way that the Googlebot wants it done to get best results. What about Flash or Silverlight or JavaFX? Flash will get you screwed on about the same level as JavaScript. Silverlight or Java might as well be black holes. Whatever is in there, is never getting out.

There are tricks you can employ like progressive enhancement. There you do things the way that the Googlebot wants them, then dynamically obliterate that garbage and replace it with rich content that your users actually want. This can backfire. If the Googlebot figures out that you are tricking it, then it will banish you to purgatory.

What if you just make a great web application that users will love and don't bother to worry about the Googlebot? That's fine of course, it just means that people will not find your application by searching for it. Is your business model and marketing efforts robust enough to not need SEO? Yeah, I didn't think so.

So now do you understand? The Googlebot ties your hands, or at the very least makes you jump through all kinds of hoops. There are all these great technologies you could use to make your site as interactive as any desktop application, but The Googlebot does not like this. You've got to play his game whether you like it or not.

Slides from AjaxWorld

Posted by somebody else! Thanks!

Netapp Michael Galpin

View SlideShare presentation or Upload your own. (tags: ajaxworld-2008)

Gears and Flash

Tonight I launched up Firefox 3, and it informed there was an update to Gears ready to install. I went for it, and sure enough Gears was now working with Firefox 3! I didn't find any official announcement about this, but I didn't let that stop me from finishing an idea I had last week: getting Gears and Flash to work together.

This was not too hard. It is just a matter of using ExternalInterface to create a bridge between the two worlds. I wrote a quick POC, using a simple DB table for storing name/value pairs. I think it would be fun to re-implement the flash.data package that is normally only available in AIR apps...

Here is the JavaScript code:

function dbCall(sql, args){

    var db = google.gears.factory.create('beta.database');
    var rs = null;
    try{

        db.open('database-test');
        db.execute('create table if not exists little_table (key varchar(20), value varchar(100))');
        rs = args ? db.execute(sql, args) : db.execute(sql);
        data = [];
        while (rs.isValidRow()){

            row = {};
            for (var i=0;i<rs.fieldCount();i++){

                var name = rs.fieldName(i);
                row[name] = rs.field(i);
            }

            data.push(row);
            rs.next();
        }
        return data;
    } finally {

        rs.close();
    }
}

Here is the ActionScript code:

import flash.external.ExternalInterface;
 

[Bindable]
private var rs:Array = [];
 
private function load():void{

    rs = ExternalInterface.call('dbCall', 'select * from little_table');

}
private function save():void{
    var key:String = keyIn.text;
    var value:String = valueIn.text;
    ExternalInterface.call('dbCall', 'insert into little_table values(?,?)', [key, value]);
    keyIn.text = "";
    valueIn.text = "";
    load();

}
private function clearData():void{
    ExternalInterface.call('dbCall', 'delete from little_table');
    load();

}

And here is the MXML I used to test it out:

<?xml version="1.0" encoding="utf-8"?>

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" initialize="load()">
    <mx:DataGrid x="202" y="59" id="grid" dataProvider="{rs}">

        <mx:columns>
            <mx:DataGridColumn headerText="Key" dataField="key"/>
            <mx:DataGridColumn headerText="Value" dataField="value"/>

        </mx:columns>
    </mx:DataGrid>
    <mx:Label x="10" y="251" text="Key"/>

    <mx:TextInput x="74" y="249" id="keyIn"/>
    <mx:Label x="242" y="251" text="Value"/>

    <mx:TextInput x="285" y="249" id="valueIn"/>
    <mx:Button x="460" y="249" label="Save" click="save()"/>

    <mx:Button x="243" y="298" label="Clear" click="clearData()"/>

</mx:Application>

Silverlight Stocks

Ever since details of Silverlight 2.0 came out, I planned on re-doing my stocks app using it. This is an app that I first wrote for a GWT tutorial I did for IBM, and then re-wrote when I learned Flex last year. I wanted to write it in Silverlight last year, but Silverlight was not ready then. Now it is. Here's a picture of it.


This look-and-feel is all defaults. It looks like a web page! It's usually easy to spot Flex apps, but that is not as true with Silverlight. Everything works the same as with the Flex or GWT versions, except the color-coding for stocks that are up or down. I figured out how to define styles with Silverlight (more on that) but could programmatically set the style. Let's take a look at the code. First the UI code.

<UserControl x:Class="SilverStocks.Page"
    xmlns="http://schemas.microsoft.com/client/2007" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    Width="400" Height="300">
    <StackPanel Orientation="Vertical">
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="Enter Symbol "/>
            <TextBox x:Name="symbol" Width="100"  KeyDown="symbol_KeyDown"/>
            <Button Click="Button_Click" Content="Get Info" />
        </StackPanel>
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="Company Name: "/>
            <TextBlock x:Name="company"/>
        </StackPanel>
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="Price: "/>
            <TextBlock x:Name="price" Text="$"/>     
        </StackPanel>
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="Change: "/>
            <TextBlock x:Name="change" Text=""/>     
        </StackPanel>
    </StackPanel>
</UserControl>

Pretty similar to MXML, but distinctive. As with ASP.NET pages, Silverlight puts all code in a code-behind file:

    public partial class Page : UserControl
    {
        const string url = "http://localhost:8080/Stocks/Stocks?symbol=";
        public Page()
        {
            InitializeComponent();
        }

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            invokeStockService();
        }

        private void invokeStockService()
        {
            string symbol = this.symbol.Text;
            WebClient service = new WebClient();
            service.DownloadStringCompleted += new DownloadStringCompletedEventHandler(handler);
            service.DownloadStringAsync(new Uri(url + symbol));
        }

        private void handler(object sender, DownloadStringCompletedEventArgs args)
        {
            if (args.Error == null)
            {
                this.showInfo(args.Result);
            }
        }

        private void showInfo(string xmlContent)
        {
            XDocument root = XDocument.Parse(xmlContent);
            var stocks = from xml in root.Descendants("stock")
                        select new Stock
                        {
                            Symbol = (string) xml.Element("symbol"),
                            Company = (string) xml.Element("companyName"),
                            Price = Decimal.Parse((string)xml.Element("price")),
                            Change = Decimal.Parse((string)xml.Element("change"))
                        };
            foreach (Stock stock in stocks)
            {
                this.company.Text = stock.Company;
                this.price.Text = stock.Price.ToString();
                this.change.Text = stock.Change.ToString();
            }
        }

        private void symbol_KeyDown(object sender, KeyEventArgs e)
        {
            if (e.Key == Key.Enter)
            {
                this.invokeStockService();
            }
        }
    }

Notice that I used the LINQ-XML cleverness, as advocated by Scott Gu. Most dynamic language folks will probably favor ActionScript's E4X over using this lambda-ish query language and a statically defined class. Actually I'm sure I could refactor this to not use the class at all, and just set the text fields during the query.

Finally, the other major difference between the two is the Flex framework's mx:HttpService. This component encapsulates the call to the back-end and provides dynamic binding. There is no handler code in the Flex version because of the binding. Will data source bindings and components like mx:HttpService find their way in to Silverlight?

No Silverlight for You

I attended an MSDN talk this week on Silverlight. It was given by Microsoft evangelist Anand Iyer. If you've been to any Microsoft developer centric events in the Bay Area, chances are that you've got to listen to Anand. He's an excellent speaker and this week's talks were no different. One of the things that makes his talks so good is the honesty. There's no BS, marketing spin.

My chief interest in Silverlight is as an "RIA" technology. I put RIA in quotes because there are different interpretations of that acronym. I was used to a definition similar to the one in Wikipedia: Rich Internet Application. The key in this definition is bringing a desktop-like experience to web applications.

Microsoft's definition is different. They call RIAs: Rich Interactive Applications. To them it is not about web applications with a desktop-like experience. It's about media. This may seem like a minor point, but actually it's the only point worth mentioning to me. It was the most important thing I took away from Anand's speech: Microsoft is only interested in rich media when it comes to Silverlight.

This seemed contradictory to me. After all, they've made a big deal about bringing the CLR to Silverlight 1.1. But Anand was crystal clear on this. If you want to build web applications, then you should be using ASP.NET and all of its great AJAX goodness. You can use Silverlight, but it's going to be very difficult as this is not the focus of Silverlight.

Indeed this message is consistent with the use of Silverlight. You can create a Silverlight application in Visual Studio 8, but you're going to be editing XAML, i.e. XML. Essentially you're creating low-level vector graphics commands wrapped in XML. One of the other attendees at the MSDN talk asked Anand if there is any kind of nice designer that was going to be built in to Visual Studio to make this easier and the answer was "Yes there will be a design view, but it is awful. You need to use Expression Blend."

And there it is. If you want to do Silverlight work, you need Blend. This is a tool made for designers and is not even available to MSDN subscribers. This tool is not meant for developers, and thus Silverlight is not meant for developers.

It's only meant for designers. It's only meant for creating animations or embedding video, etc. That's all Microsoft is going for. Imagine if Adobe got rid of Flex and said "you have to use Flash CS3." That's Microsoft's position.

Again with CLR support built into Silverlight, you might think that it's just a matter of time before it becomes a developer platform. But from what Anand had to say, it's going to be a long itme. There's not going to be developer support in Silverlight 1.1 and Visual Studio 8. VS8 won't be shipping until February and Silverlight 1.1 won't be shipping until next summer. Given that, I would have to guess that it will be at least two years before Silverlight becomes something that can be used by developers. That's truly disappointing.