It has been well on nine months since I last posted, and I am nothing short of disgusted with myself – a guy who promotes blogging regularly, even if it is just a short post. In a classic case of “do as I say, not as I do,” I got so lost in a major project – unexpectedly so, may I add – that time for blogging disappeared faster than newly released iPads do from store shelves.

The project took me back to my online product development roots, and allowed me to build an incredible analytics system for mobile devices. I figured I knew how to build algorithms and real-time search engines, so it might be good for me to know how to build the analytics system that measures the results and feed them back into the behavior of the engine.

I am now officially hooked on mobile as part of the repertoire. Mobile today reminds me of the web in 1996 – 1998 – it is the wild west of technology markets. The rise of smartphones and tablets has changed the entire dynamic of how people interact with information. Everyone is experimenting, and their are thousands of small firms making bets on various approaches to mobile. Evolution is fast and furious, with winners and losers coming and going almost overnight as market changes and technology enhancements literally create disruptive change in the ecosystem.

One ongoing technology argument is HTML5 versus native apps and whether HTML5′s advantages of cross-platform compatibility, channel freedom (not being dependent on the app stores), enhanced discoverability due to better search engines, large base of developers, better analytics tools, and substantially lower cost of development will cause it to overtake native app development as the platform of choice for next-generation mobile apps.

I was at the AppNation conference last week and Trip Hawkins – someone who knows about as much about mobile gaming as anyone – weighed in.

“The browser will beat the app store,” he argued. “It’s more convenient, it’s driven by search and it’s more viral for consumers. It doesn’t matter what device your friend has… All technologies start as silos, but get 100 times bigger when they become inter-operable; think about roads or text messaging.”

I agree with him completely – ubiquity trumps functionality every time, and ultimately the ubiquitous platform surpasses the proprietary platform because more people invest in evolving it to do what they need it to do. Think open source and the “community of the commons” which helped evolve platforms like Java, Linux, Twitter, and Facebook. Or even more fundamentally and applicable to the HTML5 discussion, think the original Apple versus Microsoft Windows. Windows ultimately dominated – and still dominates – Apple as a platform because Microsoft early on allowed its OS to be licensed to any hw manufacturer, extending the franchise and opening the market to an overwhelming level of app development investment that to this day dwarfs what Apple can offer.

This is the economic law that Brian Arthur has described and quantified in his evolving work on Complexity Economics and something we all understand intuitively nowadays. That is, the value of the network (think technology network) increases as it becomes more ubiquitous, thus drawing more investment into it which only further increases its value. It is a virtuous cycle, and one reason becoming the market share leader in a new technology is so critical.

Apple has learned a few things over the years, and with the iPhone and iPad they have quickly moved to gain dominant share and the largest developer community. They are evolving their tools for developers and their OS faster in order to keep their developer community growing and provide more opportunities for developers to make money on the platform. It gives Apple a tremendous lead and advantage at this point against any open platform alternative.

But developing native apps is, relative to HTML5, time consuming and expensive. Unless you are in an industry like gaming where the quality of immersive graphics and performance is critical, HTML5 offers a cost and time to market advantage that provides a lower barrier to entry into the mobile market.

Then there is also an arrogance to Apple that is driving developers to consider ways to bypass the platform. Consider:

• The iTunes store is a bottleneck. It is a single place to sell, and it gives Apple tremendous power over who succeeds and who does not. And Apple has been more than willing to display its dominance to developers and the community at large.
• There is a relatively and unpredictably long approval process to get an app live, and often apps are rejected for issues that were not apparent in advance.
• Apple changes the rules continuously and in many people’s minds, arbitrarily. Take the recent paid download spat with Tapjoy and others. In a single dictum, Apple basically removed a major monetization mechanism for developers.
• You cannot tell when a push notification actually goes out through Apple. So you pay someone like Urban Airship to send the token to Apple, but then about 1/3 of the time the pushes never arrive. Apple is a “black box” on this and won’t tell you why (although they say they are working to fix this). Now if that isn’t arrogance, I don’t know what is.
• Apple keeps track of everything developers’ users do on their platform, but do not make the data easily accessible to allow developers to improve their products and optimize their revenues.

All of this give Google and Windows 7 a potential opening to exploit HTML5′s advantages, and they will. Google is already doing so, although they are to a certain extent hedging their bets right now. And Facebook pushing HTML5 apps gives the platform momentum. Eric Schmidt was at Sun with me when Java came to market, and knows first-hand how to leverage an open platform to disrupt an entrenched proprietary competitor. Voila Android. And very soon, Android devices will have a larger installed base than iOS, if it doesn’t already.

The weakness Android has in the app market is fragmentation. In my limited experience looking at the data, there have got to be at least 30 variations of Android out there. When you look at the ROI for developing on Android, it only pays to develop for one or two versions – and this sentiment has been documented extensively in magazines like Fortune .

But that argues strongly for using HTML5 as a development platform. It allows developers to undercut Apple’s power position in the industry and develop for all Android phones.

HTML5 thus provides the opportunity to develop faster, cheaper, with a wider audience to sell to. And Apple is more than providing the motivation, just like Microsoft did for Java. As a rule, developers are a libertarian bunch who hate being dictated to by anyone, and they are getting increasingly upset with Apple.

The only question is how fast this transition will occur, and that remains to be seen. I think ABI Research is right when they say that native app development will peak in 2013 – that just feels right to me given my experience with numerous technology adoption cycles. But any prediction like that is fraught with peril. On the one hand, some killer mobile app built on HTML5 can come along tomorrow and change user behavior to the point where the browser becomes a natural first point of entry into a mobile device. On the other, Apple could change its modus operandi and salve the wounds of upset developers.

So while it is a matter of time, developers for now will have to make a bet on when HTML5′s time will come.

So here for all who could not attend, is a summary of three of the sessions I attended on the first day of SMX Advanced 2010.  I only get so much time to blog…working guy you know.  I’ll do my best to post the rest, but no promises.

SEO for Google versus Bing

Janet Miller, Searchmojo

• From heatmap studies, it appears people “see” Bing and Google SERPs in pretty much the same way.  The “hotspots” are pretty similar.
• Not surprising: average pages/visit and time on site are higher for Bing than Google – but that has always been true from my perspective
• Bing does not currently accept video or news sitemaps.
• On Google you can edit sitelinks in Webmaster tools, in Bing you cannot.
• Geolocation results show pretty much the same in both sets of results.
• One major difference:  Google shopping is free for ecommerce sites to submit; Bing only has a paid option for now.
• Bing lets you to share results (social sharing) on Facebook, Twitter, and email, Google does not.  But the sharing links point back to the images on Bing, not to the original images on your site.  You also have to grant access to Bing on Facebook.
• Bing allows “document preview” when you rollover the entry.  It will also play videos in preview mode – but only those on youTube.  If you look at the behavior, information from the page shows up.  To optimize the presentation of that information, Bing takes information in this order:
• • H1 tag first – if title tag and h1 tag don’t match, it takes the H1 tag
  • First paragraphs of information
  • To add contact info, add that information to that page.  Bing is really good about recognizing contact information that is on a page.
  • • Address
    • Phone
    • Email
    • To disable “document preview” enter the following
      • Add this meta tag to the page: <meta name=“msnbot”, content=“nopreview”>
      • Or add this line to robots.txt: x-robots-tag: nopreview

    Rand Fishkin: Ranking Factor Correlations: Google versus Bing

    As usual, Rand brought his array of statistical knowledge to bear to compare how Bing and Google react to different ranking signals.  Here are the takeaways:

    Overall Summary of Correlations with Ranking, in Order of Importance

    Bing	Google
    Number of linking root domains An exact match of .com domain name with desired keyword Linking domains with an exact match in the TLD name Any exact match of the domain name with the desired keyword Number of inbound links	An exact match of .com domain name with desired keyword Linking domains with an exact match in the TLD name Number of linking root domains Any exact match of the domain name with the desired keyword Number of inbound links

    Domain Names as Ranking Factors

    • Exact match domains remain powerful ranking signals in both engines (anchor text could be a factor, too).
    • Hyphenated versions of domain names are less powerful, though when they show they show more  frequently (more times on a page)  in Bing (G: 271 vs. B: 890).
    • Just having keywords in the domain name has substantial positive correlation with high rankings.
    • If you really want to rank on a keyword, make sure you get exactmatchname.com as the TLD.
    • Other exact match domains may still help, but don’t have as high correlation.
    • Keywords  in subdomains are not nearly as powerful as in root domain name (no surprise).
    • Bing may be rewarding subdomain keywords less than before (though G: 673 vs. B: 1394).
    • On alternate TLD extensions:
      • Bing appears to give substantially more weight to these than Google.
      • Matt Cutts’ claim that Google does not differentiate between .gov, .info and .edu appears accurate.
      • The .org TLD has a surprisingly high correlation with high rankings  but you can attribute this to elements of their authority – more links, more non-commercial links, Less spam.
      • Don’t forget the exact match data  .com is still probably a very good thing (at least own it).
      • Shorter URLs are likely a good best practice (especially on Bing).
      • Long domains may not be ideal, but aren’t awful.

    On-Page Keyword Usage

    • Google rankings seem to be much more highly correlated with on-page keyword usage than for Bing.
    • The alt attribute of images shows significant correlation as an on-page ranking factor. (I always thought so and it’s one of the elements most SEO newbies miss.)
    • Putting keywords  in URLs is likely a best practice.
    • Everyone optimizes titles (G: 11,115 vs. B: 11,143).  Differentiating here is hard.
    • (Simplistic) on-page optimization isn’t a huge factor.
    • Raw content length (length of page and number of times the keyword is mentioned on the page) seems to have only a marginal correlation with rankings.

    Link Counts and Link Diversity

    • Links are likely still a major part of the algorithms, with Bing having a slightly higher correlation.
    • Bing may be slightly more naïve in their usage of link data than Google, but better than before.
    • Diversity of link sources remains more important than raw link quantity.
    • Many anchor text links from the same domain likely don’t add much value.
    • Anchor text links from diverse domains, however, appears highly correlated.
    • Bing seems more Google-like than in the past in handling exact match anchor links (this is a surprise!).

    Home Pages

    • Bing’s stereotype holds true: homepages are more favored in top results vs. Google.

    Twitter, Real-Time Search, and Real-Time SEO

    Steve Langville – Mint.com

    Steve had a lot of interesting points, and I thought his approach to real-time was one of the most sophisticated I had heard.

    1. One element of his strategy is what I like to call “Merchandising Real-Time Search.”    Basically someone at Mint has a merchandising calendar of important dates/topics in consumers financial lives (e.g. tax time) and also watches for hot topics that could impact a consumers sense of money (e.g. new credit card legislation).  Mint then has a team that can create new content on that topic that is likely to generate word-of-mouth.  At that point, they push the content out and then energize their communities on Facebook, Twitter, etc. by promoting the content to them.  This generates buzz and visits back to mint.com.
    2. Mint has also created Mint Answers, it’s own Yahoo Answers-like site where people ask and answer questions on financial topics.  The result is a lot of user generated content on Mint.com on critical keywords that yields high ranking in the SERPs.
    3. Mint also developed as Twitter aggregator widget around personal finance and put this as a section on their site.  Twitter’s community managers then retweeted these folks who then signed up for @mint and began retweeting @mint tweets.  According to Steve, the amplification effect was huge.

    Danny Sullivan

    As always, Danny had some really interesting insights to add about real-time search.  I will honestly say that many times I still think Danny, like many search marketers, thinks “transactionally” about search , as compared to consumer marketers who think about having an on-going “conversation” with a customer.  (More on that notion later).  But in this case, Danny really showed why he is known as an industry visionary:

    • Search marketing means being visible wherever someone has overtly expressed a need or desire.  It is more than web; more than keywords.  An example is mobile apps –  search by another name- so I guess he agrees with Steve Jobs on that one.
    • This was uniquely insightful. Whereas normal search is a many-to-many platform where anonymous individuals post  content whose authority grows based on “good” links that are added over time, real-time search is a one-to-one platform where clearly identified people post questions or comments  and get responses.  Authority comes from the level of active engagement, not links.  I had never heard real-time described this way, and it is a succinct but very sophisticated definition of real-time search.
    • You can use conversations to identify folks interested in what you need. Not a new concept, but good to repeat.  So if you have a service that sells vacuum cleaners, search for “anyone know vacuum cleaners” and the folks who have an interest are now identified and you can respond to them.
    • Get a gift by giving a gift. That’s the fundamental currency of social media. Danny answered 42 questions from people who didn’t know him, didn’t follow him.  He got no complaints and 10 thank yous.
    • Recency versus Relevancy. Anyone doing real-time gets this – that authority can come from having high-quality information or having reasonably high quality information in a very short time frame – in other words, sometimes the recency of news makes it more worthy of attention than something older but more thought out.  Danny believes that as Twitter matures (and maybe the entire real-time search business – that wasn’t clear), relevancy is going to get a higher relative weighting, so that relevant results will get more hang time in the SERPs.

    Chris Silver-Smith

    I have trouble summarizing all of Chris’s talk – and it was a very good talk – because so much of what he talked about was covered in my notes from other speakers.  So here are the unique points from his chat:

    • You have to decide how you resource Twitter and other sites.  Questions to ask for your strategy
      • Consumers First: What are consumers saying about your site/company already? How might they use your Twitter content? Develop representative Personas of consumers who would engage with you on Twitter.
      • Time/Investment: How much time do you have to devote to Twittering? Do you devote someone to spend time dailyreading/responding to Tweets?
      • Goals: What are some advantageous things you could accomplish by interacting with consumers in real-time?
      • Strategy will decide whether you hire a full-time person, part-time person, or use automation.
      • Use OAuth for API integration as it shows the application the visitor used as an appended data point
      • Convert your Google News feeds to RSS to make them easier to subscribe to by members of your community
      • A great tool for small business social media management is www.closely.com which auto-creates a social action page for every offer a company makes on Twitter and Facebook
      • Be brief but really clear in main point on Tweets. Include a call to action as they are retweeted at a much higher rate.
        • Tweets with please were retweeted ~5.5% of the time versus 0.5% for random Tweets.
        • 98% of usernames on Twitter are 12 characters or less. So make your tweets no longer than 125 characters to allow for RT addition with username.
        • Top 10 common words in retweets are (in order of most mentioned): you, Twitter, please, retweet, post, blog, social, free, media, help.
        • Use custom features in URL shorteners to include your desired keyword on which to rank in the shortened URL.
        • Resources to check out:
          • http://collective-thoughts.com/2009/02/20/social-bites-like-sound-bites-butdifferent/ (Retweet tips – perfect “social bite”)
          • http://www.danzarrella.com/the-20-words-and-phrases-that-will-get-you-the-most-retweets.html
          • The Science of ReTweets:
            • http://mashable.com/2009/02/17/twitter-retweets/
            • www.semclubhouse.com/special-characters-for-twitter/ (Special characters)

    John Shehata – Advanced Internet

    I loved John’s presentation because it confirmed many of the same conclusions I had reached about real-time search and reported on at SMX Advanced in London.  Key points:

    • The ranking factors for real-time search are very different. They include:
      • User (author) authority (My comment:  not just one site but across every site  on which the author publishes).
      • How fresh that author’s content continues to be.
      • Number of followers.
      • The quality of follows and how they act on the author’s content (is it retweeted often?  Is it stumbled?  Does someone flow it into their RSS feed?  How often?  How quickly?).
      • URL real-time resolution.
      • It is not about how many followers you have but how reputable (authoritative) your followers are.  (This is what I call Authorank and like PageRank it is passed from authoritative follower to those they follow.)
      • You earn reputation, and then you give reputation. If lots of people follow you, and then you follow someone–then even though this [new person] does not have lots of followers, his tweet is deemed valuable because his followers are themselves followed widely.
      • Other possible ranking factors:
        • Recent Activity : Google pays more attention to accounts with more activity?
        • User name: keywords in your user name might also help.
        • Age: since age plays a big role in Google search engine ranking, it’s possible that more established Twitter accounts will outrank the newer ones.
        • External links: links to your @account from (reputable) non-social media sites should boost reputation as far as Google is concerned.
        • Tweet Quantity: the more you tweet, the better chance you’ve got to be seen in Google real-time search results.
        • Ratios of followed vs follow: a close ratio between the two can raise a red flag.
        • Lists: it might also matter in how many lists you appear.

    Tactics to follow:

    • Encourage retweets by tweeting content of 120 characters or less so you can save room for the RT @ Username that is added when someone passes along your message to their followers.
    • Tools to identify hot trends: Google Hot Trends, Google Insights, Google News, Bing xRank, Surchur, Crowdeye, Oneriot.
    • Same advice as Steve Langville – plan for seasonal keyword trends.
    • Don’t update multiple accounts, reTweet instead.
    • Connect your social profiles.
    • Attract reputable, topically-related followers.
    • Write keyword-rich tweets whenever possible, without sounding spammy:
      • Do not create content with multiple buzzing terms.
      • Do not abuse shortening services for spam links.
      • Do not go overboard using Twitter #hashtags – Search Engines will eliminate your tweet from search if you use too many because it “looks bad.”
      • Spammy looking tweet streams will be eliminated from search.
      • Don’t use same IP address for different twitter accounts.

    Show Me The Links

    This was a great session with a HUGE number of ideas for getting new links.  And each person talked about a very different philosophy towards link building and their tactics reflected those philosophies.  Let’s see if I can capture them:

    Chris Bennett

    • Philosophy centers on using easily created and highly valued visual or viral content:
      • Creating Infographics – they work very well.  An example – a “where does the money go from the 2008 stimulus bill” infographic generated 29,000 links.
      • Writing guest blog posts whose content is highly viral for others .  Embed a link to your site as the source.  You give the gift of traffic to them, you get links as a gift in return.

    Arnie Kuenn

    • More traditional link building
      • 50% is content development  and promotion.  The big example he used on this was the Google April Fools Day Prank about Google opening an SEO Shop.  Got picked up as “real” story by Newswire 27 days after post, went viral, generated 800 backlinks.
      • 20% is blog post and article placement.
      • 10% is basic link development.
      • 20% is targeted link requests to those few critical high-value sites. There are NO magic bullets here – it takes creativity and just good old-fashioned hard work and persistence.  But the rewards can be substantial.

    Gil Reich

    • Use badges with your URL embedded that benefits the person who puts on site (e.g. “a gold star” validation).
    • Write testimonials for other folks.
    • Write on sites that want good content and can deliver an audience.
    • Answer questions on answer sites where you have the expertise.
    • Make it easy to link to you by providing the information to potential linkers.

    Roger Montti

    Focused on B2B link building tactics:

    • Backlink trolling from competitors- but also look for sites that your competitors aren’t on – you want your own authoritative link network.
    • Don’t ignore TLD .us  There are lots of good possible link sites with decent authority there.
    • Look at associations that provide ways to link to their members.  Search for member lists, restrict your search to .org and add in relevant keyword phrases to filter for your related groups.
    • Look at dead sites with broken links – see who is linking to them.  Once you have identified a dead internet page do a linkdomain: search on Yahoo to identify sites still linking to the dead site.
    • Free links from resources, directories, or “where to buy” sites.
    • Bloggers:  cultivate alliances and relationships with other sites and blogs.  Particular bloggers who like to do interviews.

    Debra Masteler

    • You have all this content that you generate as a normal part of your business.  Use it.
      • Use dapper.net to create RSS feeds of your blog content
      • Joost de Valk has a WordPress plugin at http://yoast.com/wordpress/rss-footer/ which let’s you add an extra line of content to articles in your feed, defaulting to”Post from“ and then a link(s) back to your blog,with your blog’s name as it’s anchor text.
      • Use RSS feeds from news sources to identify media leads to speak with as part of your PR work.
      • Content syndication: podcasts, white papers, living stories, news streams and user generated content (e.g. gues blogging) are still hot.  Infographics, short articles, individual blogs, and Wikipedia are not.
      • Widget Bait: basic widgets that you can build on widgetbox are getting somewhat passé but still have some value.   You need to do more advanced versions – information aggregation widgets seem to work very well right now.  Make people come to you to download them.
      • Microsites: the old link wheels are worthless at this point – the engines have figured those out and treat them similarly to link spam sites.  Those with good content – e.g. blogs or sites with good content – work.  One option is to buy an established site and then rebrand it.

Google TV is the latest attempt to merge the television experience with a web-based TV (also called IPTV) experience on the television set (as compared to bringing TV to the web, as say a SlingBox does).  There have been numerous attempts to bring the Web to the television, going back all the way to 1996 when Steve Perlman, Bruce Leak and Phil Goldman brought to market the WebTV set-top box, marketed by both Sony and Phillips.  (Find a list of TV/Internet hybrids in the next post).  None of these has been particularly successful, for numerous reasons:

• Most require an extra set-top box that is expensive (Google is no different.  As an example of technology that uses the consumer’s  computer or laptop as the interface to the TV, see Kylo).
• The experience doesn’t truly integrate.  You either watch the web-based offerings or Live TV, but not both at the same time.  In many cases, the box is meant for the delivery of movies or TV shows on-demand, as compared to being broadcast in real-time.  The Roku/Netflix platform is an example of this.  PopBox is another example, but they also deliver more content – websites, social media experiences from Facebook and Twitter, images, YouTube videos, games, and music from sources like Photobucket and Pandora.
• The interface requires a separate remote control, which adds another layer of complexity to the consumer experience.

None of these really impacts the effectiveness of a “single” broadcast TV advertisement in any meaningful way.  They are separate experiences from broadcast television and, as a rule, they do not take away from live TV viewership.  Some amount of consumers’ time is given to the Internet and movies on-demand nowadays.  Whether I interface with that experience through my computer screen or TV screen doesn’t change the amount of time I spend in an “online” mode versus a TV viewing mode, and it does not impact my current behavior around the TV ads themselves.

Google TV has come up with a different approach which, at least during an initial search, overlays the Internet on top of the television experience (see first image).  When it overlays, the interface is transparent so you can see your TV behind the browser interface that lets you search for the shows and information you want.

There are other times when the interface switches completely and the TV experience is put on hold while the viewer interacts with Web content (see second image), which is more like the experiences of the current generation of web-to-TV offerings.  But the difference here is how easy and seamless Google TV makes it to switch between all three of these user experiences – live TV, TV in the background, and Internet-only.  The other difference, and one of critical import for this article, is that Google intends to sell advertising within the Google TV platform.  Where, how, and how much are still to be determined.

Google has definitely come up with something unique that I believe will be very compelling to television viewers as it now truly integrates the television and web experiences for the first time.

But if the consumer loves this, traditional TV advertisers should hate it.

Today, television advertising is a $70B market versus $25B for Internet and mobile search advertising.

In 2010, TV advertising is projected to grow 4.3%, or $3 billion on a base of $70.2 billion. This compares to non-search on-line advertising which is projected to grow 12.9% or $1.6 billion on a base of $12.2 billion during this period.   So even though Internet advertising is growing at a faster rate, television advertising real-dollar growth is twice that of Internet advertising.

Google knows this.  Rishi Chandra, the  product manager for Google TV, mentioned the $70B factoid at Google’s I/O conference last week.  Moreover, Google also gets that despite the fact consumers are spending an increasing number of hours per day online,  television viewership is at an all-time high, with 180mm US consumers watching TV for over 5 hours/day on average.  Rishi mentioned this, as well. The guys at the Googleplex are no dummies. As the old saying goes, they can see a mountain in time. In this case, the mountain they want to cash in on is TV advertising.

What both Google and the advertisers also know is that television advertising is broken.  In 1987 an advertiser could reach 80% of viewers by airing a 30-second spot only three times. Today, that same commercial would have to air 150 times to reach 80% of viewers.[1] The rapid decline of TV ad viewership is due to the “TiVo” effect and today’s viewers’ multi-tasking habits – texting, phoning, emailing and web surfing while watching TV.  Brands are urgently seeking a solution to reengage viewers of their TV commercials as brand expenditures on television dwarf what they spend on all other ad mediums.

Now Google would argue that it has found the solution, and from its perspective I truly think they believe this.  The Google culture is driven by data and metrics.  Current television advertising with its lack of performance measurement is anathema to a Googler’s mindset.   If you are a fanatic about data-driven marketing, Google TV “solves” this problem because of its ability to bring CPC and other easily measurable formats into the web-based part of the new integrated television experience.

Interesting and correct as far as it goes.  But wrong – and I mean dead wrong – from the perspective of television advertisers who focus 3x of their dollars on television versus online advertising because it is still the most potent means of getting a message to the consumer.  Moreover, it is a power play by Google to disconnect the brand advertisers from their traditional advertising providers and drive them, willingly and like lemmings, onto the Google platform(s), thus providing Google an even stronger power position relative to advertisers.

Let’s think about this.  Television advertising is already much less effective than it used to be.  Now along comes Google TV with its overlay and ability to seamlessly move away from the live television experience.  Let’s say you are a viewer watching Lost, that you are using Google TV, and you have left your laptop in the other room because – heck – you don’t need a two-screen solution to access the Internet during live television now that you have Google TV.  Something on the show triggers you to want to look up some factoid on the web at a Lost fan site.  You plan to type in “Lost fan site.”

When are you going to type this in?  During the time the episode is airing?  Absolutely not.  You’re not going to want to miss one minute because Hurley is about to tell Jack his real name.    Or take another example – a sports case.  Are you going to put the potential touchdown play in background mode while you look up Brett Favre’s completion percentage in third down and long situations?  Absolutely, positively not, to the extent that the sports fan is thinking “don’t you dare touch the remote or there will be one less thumb in this family.”

No.  You are going to switch to the Internet experience when the television ads come on and you can safely move away from the live broadcast to find what you need before your show comes back on.

There is another interesting fact that only makes this seem a more likely behavior on the part of cross-platform TV viewers, at least the early adopters of Google TV.  In a recent study of US Online TV Viewership by Comscore involving 1,800 subjects, a majority (67 percent) of cross-platform (TV and online) viewers preferred online TV viewing because it has less interference from commercials[2].  Since these folks are the likely early adopters of Google TV, the tendency to move away from live TV during commercials will be very strong.

So what does Google TV do?  It makes the television ad spend of the major brands even less effective than currently.  Because Google TV still provides an interruptive experience, it actually encourages cross-platform viewers who wish to increase the “information content” of their viewing experience from web-based channels to do so at the exact time that advertisers least want them to do so.

There is an even bigger implication of this for brand advertisers.  In order to keep the cross-platform consumer’s attention as they move away from viewing television ads, the brand advertisers will be forced to place their ads on the web-based portion of the Google TV interface.  And to a certain extent this makes sense going back to our previous point about measurability of TV advertising.  The Google platform is measurable and consumers more and more are becoming habituated to interacting with web-based CPC or banner advertising.  So the TV advertiser keeps the attention of the cross-platform viewer during the commercial break in the show and gets better metrics.  It’s an obvious win-win for both Google and the advertiser, and a very seductive business proposition to marketing executives looking for better measurability around TV advertising.

But for TV advertisers, Google TV is the equivalent of the poison apple given to Sleeping Beauty.  As Google TV penetrates households, more and more TV viewers will become habituated to the dual-use experience and will spend more and more time on the Google platform during broadcast television advertising pods.  And despite the fact I haven’t said much about mobile in this article until now, Google TV will also move onto the mobile platform and will provide an even more integrated experience for the consumer across the two screens, with a whole host of implications for the two-screen experience that I won’t discuss here.  Given the timing of historical consumer behavior transitions in the television market, this could take ten years. But over that time, Google will take a larger and larger share of the currently $70B TV advertising and the $2.7B mobile advertising markets.  This means that as much as an advertiser is currently dependent on Google for web advertising, they will become even more dependent on the single provider that is Google because of its reach in these other channels.

If you as an advertiser aren’t concerned about the implications of this for your business, where Google can set effectively monopoly prices you pay for ads across every major advertising platform you have, you should be.  You should be very concerned and mad as hell at this attempt to manipulate your advertising dollars even further into the maw of the machine that Google has become.

If I were a brand advertiser right now, I would be talking to my peers and looking for a second-platform solution from someone that can constrain this power play by Google before it becomes a fait accomplice.  If I were Yahoo or Microsoft, I’d be developing or investing in a prototype of something I could show to brand advertisers today and get them to invest strategically in order to prevent Google from locking up this market before it is too late.

[2] Yuki, Tania “Comscore Study of US Online TV Viewership.” http://www.comscore.com/Press_Events/Press_Releases/2010/4/Viewers_Indicate_Higher_Tolerance_for_Advertising_Messaging_while_Watching_Online_TV_Episodes

In my last post, I posited that The Chasm, as far as Internet-based businesses are concerned, is quickly disappearing.  Let me explain why and why The Chasm has now been replaced by what I call The Rapids.

The Chasm exists because of the disconnect between

• The time/resources needed to evolve both a high-tech product and business model from meeting the needs of early adopters to support the larger market segment – the early majority.
• The money available to fund this transition, which is limited by the size of the early adopter market.  The available funds are not likely to grow until the early majority purchases the product en masse, for two reasons. First, because sales generate cash.  Second, because sales validate that the business model and product features are now positioned for scale, thus increasing the company valuation and ability to attract new third-party capital needed for growth.

Voila – A Catch 22 and birth of The Chasm.

But today’s Internet-based business startups work differently.  Thanks to new technologies and approaches to IP (open APIs, open source licensing, crowdsourcing, cloud computing, mashups), software products that used to take months and years to conceive and develop using a large number of engineering and marketing resources, can now be brought to market in a few weeks by two-three people in a condo (Sad to say, the garage crowd went upscale in the late 90s in Silicon Valley and have never really returned to their roots in the humble garage).  Without a lot of effort, they use word-of-mouth and viral techniques, as well as search engine optimization and perhaps a little PR, to acquire an initial set of customers who hopefully like the product and tell their friends.  If they are smart, they add a customer feedback tool like getsatisfaction or uservoice to their sites and begin collecting immediate, extensive, and continuous feedback from customers.  They plow this feedback into the product using daily or even hourly code pushes.

The difference in speed of product evolution between traditional high tech startups and Internet-based business startups is like the difference between the gestational period of an elephant and a virus. And that difference is one of two reasons The Chasm is quickly shrinking, and ultimately disappearing, for Internet-based business startups.

While products in both cases evolve in discrete steps, the size of the steps in the case of an Internet-based business are relatively small and from day to day customers do not see huge changes in the product they are already familiar with.  However, they get to use the product even as it is evolving, unlike the case in more traditional hardware or software businesses where customers can only engage with a new set of features when they are released in large, discrete “chunks” and not before.  As a result the early adopters are brought along even as new customers try the product.  Each step involves a group that more and more reflects the larger majority of customers until at some point the product meets the needs of the earliest of what would have been called the early majority –  who also happen to be the latest of the early adopters.  There is no ability in this case to find a demarcation between these two groups.  Customers’ perceptions of the product and their needs from the product change as the product itself changes because they experience those changes in small steps as they occur.  Obviously some early customers will chose to leave the product as it evolves, but that is true of any product at all times as customer attrition is a fact of life.  Rather, the customer need and product feature evolve in tandem in a virtuous cycle, removing any need to leap between one set of customer expectations/needs and another.

So on the one hand, the capital requirements for an Internet-based business startup have declined (and continue to decline) substantially, while the time required to evolve the product and engage customers in its evolution continues to shrink.  As a result, the challenge for Internet businesses is not The Chasm, because it effectively doesn’t exist any longer.

The new strategic challenge for Internet-based startups is sifting through the reams of data available – customer feedback, site analytics, Twitter feeds, Facebook fan pages, competitive data (of which there is much more today than ever) –  in near real-time and clearly identifying the critical strategic requirements for the business and product requirements needed to serve the core customer segments.  Whereas the traditional high tech startup has difficulty getting enough feedback and making enough changes in a short enough time to perfect the product and business model, the Internet-based business startup faces the problem of determining the key insights from a plethora of data (“the rocks”) and making those insights actionable in time frames that are more logical for a supercomputer than a human being.    More importantly, they need to have the discipline to avoid taking on too many strategic imperatives (“oversteering”) and not over-evolving the product because…well…because it is relatively easy to do.    The Internet startup isn’t crossing a chasm.  They are trying to avoid the rocks and not oversteer their course.  They are navigating The Rapids.

Since I was involved with the team that developed the Adoption Curve, it became a standard part of my repertoire as a marketer.  Like most others, it structured my views on how to approach any market for a new product innovation.

Then in 1991, along came Geoffrey Moore, a consultant with the McKenna Group, who published Crossing the Chasm. Crossing the Chasm expanded on Roger’s diffusion of innovation model.  Moore argued that there is a chasm between the early adopters of the product (the “innovators”, or technology enthusiasts and visionaries) and the early majority, who while appreciating a new technology tend to be more pragmatic about its application.  As a result, the needs and purchasing decision-making of these two groups are quite different.  Since effective marketing requires selling to the needs of a specific segment, there comes a time when young companies face a “chasm” where the features and marketing that helped them gain their early followers will not work, and thus they need to adapt their business to a new set of customers and expectations.  It takes time, energy, and a lot of experimentation to find the right new model.  But in high tech businesses,  especially prior to the Web, sales cycles tend to be relatively long (12 -18 months is not unusual).  Given that most small companies have limited resources, the number of experimental cycles they can undertake to discover the correct new model is thus limited.  This makes the transition extremely hard – limited resources, limited time and a lot of spinning of wheels until the right model is discovered.  Requires a lot of heavy lifting and long hours – and if you’ve ever been through this, you’ll know why Moore chose to call it  ”a chasm.”   It feels like a huge, almost overwhelming leap from where you are today to where you need to be tomorrow.  Even with a running start, when you take the leap to grow your company to the next level, it’s easy to miss and “fall into the chasm.”

I had been working with the technology adoption model visually in my head for almost 10 years at the time Moore published his book.  And when I saw his curve, I realized that we tend to see only what we have modeled (or had modeled by others) in our minds about how the world works.  I had been struggling with the chasm for all that time, and never saw it, even though it was staring me in the face.  I swore that the next time I had an opportunity to experience something that was at odds with my internal models of reality, I wouldn’t ‘ignore the data’ and make a concerted effort to see past the limitations of my own mind.

So Geoff.  I have one for you.  For web-based businesses, the chasm is closing and I can already see a time in the near future when it no longer becomes a barrier to a company’s transition from a customer base mainly made up of innovators to a customer base of early adopters.  The End of “The Chasm” Is Nigh.  Darwin – and the real-time web – are dealing with it.

The detailed rationale in my next post.  Right now, I need to get onto my day job.

In the last post, we had just moved aboutonlinematters.com to a privately-hosted standalone server and seen a substantial decrease is web site latency. We had seen our ratings improve in Google Page Speed from being better than 43% of similar websites to about 53% of sites. So great improvement. But we were still showing a lot of issues in ySlow and the Google Page Speed tool. These fell into three categories:

• Server Configuration. This involves optimizing settings on our Apache web server: enabling gzip for file compression, applying entity tags, adding expires headers, turning on keep-alive,  and splitting components across domains.
• Content Compression. This involves items like compressing images,  javascript, and css, specifying image sizes, and reducing the number of DOM elements.
• Reducing External Calls. This involves combining all external css and javascript files into a single file, using cookieless domains, minimizing DNS lookups and redirects, as well as optimizing the order and style of scripts.

We decided to attack the web site latency issues in stages, first attacking those elements that were easiest to fix (server configuration) and leaving the most difficult to fix (reducing external calls) until last.

Server Configuration Issues

In their simplest form, server configuration issues related to web site latency have to do with settings on a site’s underlying web server, such as Apache.   For larger enterprise sites, server configuration issues cover a broader set of technical topics, including load balancing across multiple servers and databases as well as the use of a content delivery network.  This section is only going to cover the former, and not the latter, as they relate to web site latency.

With Apache (and Microsoft IIS), the server settings we care about can be managed and tracked through a page’s HTTP headers.  Thus, before we get into the settings we specifically care about, we need to have a discussion of what HTTP headers are and why they are important.

HTTP Headers

HTTP headers are an Internet protocol, or set of rules, for formatting certain types of data and instructions that are either:

• included in a request from a web client/browser, or
• sent by the server along with a response to a browser.

HTTP headers carry information in both directions.  A client or browser can make a request to the server for a web page or other resource, usually a file or dynamic output from a server side script.  Alternately, there are also HTTP headers designed to be sent by the server along with its response to the browser or client request.

As SEOs, we care about HTTP headers because our request from the client to the server will return information about various elements of server configuration that may impact web site latency and performance. These elements include:

• Response status; 200 is a valid response from the server.
• Date of request.
• Server details; type, configuration and version numbers. For example the php version.
• Cookies; cookies set on your system for the domain.
• Last-Modified; this is only available if set on the server and is usually the time the requested file was last modified
• Content-Type; text/html is a html web page, text/xml an xml file.

There are two kinds of requests. A HEAD request returns only the header information from the server. A GET request returns both the header information and file content exactly as a browser would request the information. For our purposes, we only care about HEAD requests. Here is an example of a request:

Headers Sent Request
HEAD / HTTP/1.0
Host: www.aboutonlinematters.com
Connection: Close

And here is what we get back in its simplest form using the Trellian FireFox Toolbar :

Response: HTTP/1.1 200 OK
Date: Sun, 04 Apr 2010 00:17:06 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.0
X-Pingback: http://www.aboutonlinematters.com/xmlrpc.php
Link: <http://wp.me/DbBZ>; rel=shortlink
Content-Encoding: gzip
Cache-Control: max-age=31536000
Expires: Mon, 04 Apr 2011 00:17:06 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: Chunked
Proxy-Connection: Keep-alive
x-ua-compatible: IE=EmulateIE7

Different tools will return different header information depending on the specific requests made in the calling script. For example, Live HTTP headers, a plugin for FireFox, provides detailed header request and response information for every element on a page (it basically breaks out each GET and shows you the actual response that comes back from the server). This level of detail will prove helpful later when we undertake deep analysis to reduce external server requests. But for now, what is shown here is adequate for the purposes of our analysis.

For a summary of HTTP header requests and response codes, click here .  But for now, let’s get back to configuring our Apache Server to reduce web site latency.

Apache Server Settings Related to Site Latency

Enabling Gzip Compression

Web site latency substantially improves when the amount of data that has to flow between the server and the browser is at a minimum.  I believe I’ve read somewhere that image requests account for 80% of the load time of most web pages, so just following good image-handling protocols for web sites (covered in a later installment) can substantially improve web site latency and page loading times.  However, manually compressing images is painful and time consuming.  Moreover, there are other types of files – Javascript and CSS are the most common – that can also be compressed.

Designers of web servers identified this problem early on and provided a built-in tool on their servers for compressing files moving between the server and the browser.  Starting with HTTP/1.1, web clients indicate support for compression by including the Accept-Encoding header in the HTTP request.

Accept-Encoding: gzip, deflate

If the web server sees this header in the request, it may compress the response using one of the methods listed by the client. The web server notifies the web client of this via the Content-Encoding header in the response.

Content-Encoding: gzip

Gzip remains the most popular and effective compression method. It was developed by the GNU project and standardized by RFC 1952. The only other compression format is deflate, but it’s less effective and less popular.

Gzipping generally reduces the response size by about 70%.  Approximately 90% of today’s Internet traffic travels through browsers that claim to support gzip. If you use Apache, the module configuring gzip depends on your version: Apache 1.3 uses mod_gzip while Apache 2.x uses mod_deflate.

Configuring Entity Tags

Web servers and browsers use Entity tags (ETags) to determine whether the component in the browser’s cache, like an image or script (which are examples of an “entity”) matches the one on the origin server. It is a simple string, surrounded by quotation marks, that uniquely identifies a specific version of the selected component/entity. The origin server specifies the component’s ETag using the ETag response header.

HTTP/1.1 200 OK
Last-Modified: Sun, 04 Apr 2010 00:37:48 GMT
Etag: "1896-bf9be880"
Expires: Mon, 04 Apr 2011 00:37:48 GMT

Later, if the browser has to validate a component, it uses the If-None-Match header to pass the ETag back to the origin server. If the ETags match, a 304 status code is returned.

GET http://www.aboutonlinematters.com/wp-content/plugins/web-optimizer/cache/f39a292fcf.css?1270299922 HTTP/1.1
Host: www.aboutonlinematters.com
If-Modified-Since: Sun, 04 Apr 2010 00:37:48 GMT
If-None-Match: "1896-bf9be880"
HTTP/1.1 304 Not Modified

ETags can impact site latency because they are typically constructed using attributes that make them unique to a specific server. ETags won’t match when a browser gets the original component from one server and later tries to validate that component on a different server, which is a fairly standard scenario on Web sites that use a cluster of servers to handle requests. By default, both Apache and IIS embed data in the ETag that dramatically reduces the odds of the validity test succeeding on web sites with multiple servers. If the ETags don’t match, the web client doesn’t receive the small, fast 304 response that ETags were designed for.  Instead,  they get a normal 200 response along with all the data for the component.  This isn’t a problem for small sites hosted on a single server. But it is a substantial problem for sites with multiple servers using Apache or IIS with the default ETag configuration.  Web clients see higher web site latency, web servers have a higher load,  bandwidth consumption is high, and proxies aren’t caching content efficiently.

So when a site does not benefit from the flexible validation model provided by Etags, it’s better to just remove the ETag altogether. In Apache, this is done by simply adding the following line to your Apache configuration file:

FileETag none

Expires Headers

The Expires header makes any components in an HTTP request cacheable. This avoids unnecessary HTTP requests on any page views after the initial visit because components downloaded during the initial visit, for example images and script files, remain in the browser’s local cache and do not have to be downloaded on subsequent requests. Expires headers are most often used with images, but they should be used on all components including scripts, stylesheets, and Flash components.

Browsers (and proxies) use a cache to reduce the number and size of HTTP requests, making web pages load faster.  The Expires header in the HTTP response tells the client how long a component can be cached. This far future Expires header

Expires: Thu, 15 Apr 2020 20:00:00 GMT

tells the browser that this response won’t be stale until April 15, 2020.

Apache uses the ExpiresDefault directive to set an expiration date relative to the current date. So for example:

ExpiresDefault "access plus 10 years"

sets the Expires date 10 years out from the time of the request.

Using a far future Expires header affects page views only after a user has already visited a site for the first time or when the cache has been cleared. Therefore the impact of this performance improvement depends on how often users hit your pages with a primed cache. In the case of About Online Matters, we still do not get lots of visitors, so you would expect that the impact of this change to the server would have little impact on our performance and, indeed, that proved to be true.

Keep Alive Connections

The Keep-Alive extension to HTTP/1.0 and the persistent connection feature of HTTP/1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over the same TCP connection. What this does is prevent an extra HTTP request/response for every object on a page, and instead allows multiple objects to be requested and retrieved in a single HTTP session.  HTTP requests require a three-way handshake and have built in algorithms for congestion control that restrict available bandwidth on the startup of an HTTP session.  Making multiple requests in a single session reduces the number of times congestion control is invoked.  As a result, in some cases, enabling keep-alive on an Apache server has been shown to result in an almost 50% speedup in latency times for HTML documents with many images.  To enable keep-alive add the following line to your Apache configuration:

KeepAlive On

Is The Configuration Correct?

When I make these various changes to the server configuration, how can I verify they have actually been implemented?  This is where the HTTP headers come into play.  Let’s take a look at the prior response we got from www.aboutonlinematters.com when we made a HEADERS request:

Response: HTTP/1.1 200 OK
Date: Sun, 04 Apr 2010 00:17:06 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.0
X-Pingback: http://www.aboutonlinematters.com/xmlrpc.php
Link: <http://wp.me/DbBZ>; rel=shortlink
Content-Encoding: gzip
Cache-Control: max-age=31536000
Expires: Mon, 04 Apr 2011 00:17:06 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: Chunked
Proxy-Connection: Keep-alive
x-ua-compatible: IE=EmulateIE7

The line items in blue show that Gzip, expires headers, and keep-alive switches have been implemented on our server.  ETags won’t show in this set of responses because ETags are associated with a specific entity on a page.  They show instead in tools that provide detailed analysis of HTTP requests and responses, such as Live HTTP Headers or Charles.  No ETags should be visible in an HTTP request or response if FileETag: None has been implemented.

Results

We made changes in two steps.  First we activated Gzip compression, Expires Headers and removed ETags.  These changes made only negligible changes in overall web site latency.  Then we implemented the keep-alive  setting.  Almost immediately, our site latency improved in the Google Page Speed tool from being better than 53% of similar sites to being better than 61%.

We’ll stop there for today and pickup on content compression in the next installment.

I will continue with tool review going forward, but I’m finding that I need to document our work on our website performance as we go along or else we lose the data from the intermediate steps, and there have already been several that have been implemented. So let me bring you up to speed.

After my last post about the site and reviewing the data from the Google Site Performance tab in Google Webmaster tools, I was able to visualize (see the image) what was going on. As the image shows, performance jumped around substantially from mid-September, when I started the blog, until early-mid December. These jumped did not coincide in any major way with the debugging and latency improvements that I had been working on. Except for December – around the time of my last post. That seemed to have cut my latency in half – which was what pingdom had shown. So perhaps I was moving in the right direction.

Things continued to improve steadily through January – even though I had not changed any further settings. This again suggested that the fact I was hosted on a shared server and that perhaps my ISP had improved the performance of that server might be the reason for unpredictable performance changes, good or bad. But then in mid-January, I started to see a jump in latency times again.

At the same time, I wanted to continue debugging AboutOnlineMatters site latency and implement some of the changes from ySlow, such as gzip, entity tags, and expires headers. To do that, I needed direct access to my Apache Server. Given these two facts, I decided that it was time to remove the server as a factor and host the blog myself.

On February 6, we moved the site onto our own hosted setup. This is basically a dedicated server (we do have a few other small sites running, but they are using insignificant server resources) and I have direct access to all the configuration settings. From that time forward, as the chart shows, site latency has decreased continually until it is now at close to it’s historical lows.

I’ll leave it there for now – following my rule of short posts. We’ll pick up the next steps I took tomorrow.

My fellow classmates use your blogs as our reference materials. We look out for more interesting articles from your end about the same topic . Even the future updates about this topic would be of great help.

What a nice compliment. I wouldn’t be a very good marketer if I didn’t respect the wishes of my ‘customers.” So, I continue the series on web site performance issues and my saga to improve the performance of this blog. Having said that, a number of things have happened since that last post.

First, as noted in a previous post , I had the opportunity to go to SMX West earlier this month. While there, I attended a session titled “Diagnosing Technical SEO Issues”, with Adam Audette, Patrick Bennett, Gabe Gayhart, and Brian Ussery as the panelists.  One thing I learned is that the term “site performance” has a general usage different than what I am covering here.  Site performance is usually defined as including:

• How easy a site is to crawl.
• Infrastructure issues, including URL structures, template coding, directory structures,  and file naming conventions.
• Latency issues such as html redirects, http headers, image compression, and all the other items I have been covering in this series.

The point is, what this series of posts are about is only one element of site performance which is web site latency and response times as seen by Google and other search engines.  In the future, I will use this technical term in these posts.  I have to decide – for purposes of rankings – whether to change the names of my posts, the URLS,  and all the core meta data to reflect this change or whether I will stay with web site performance as the keyword I want to optimize for. That decision will probably be made based on the keyword search volumes as shown in the Google Adwords Keyword Tool. (Actually I have now changed the keyword I am optimizing for to web site latency as I am testing some theories I have on page optimization in the SERps that has nothing to do with site performance. So it just goes to show…)

Second, as also noted in the third post in this series on web site latency, Google has announced and deployed a new web site performance tool within Google Webmaster Tools, as well as a Firefox/Firebug plugin.  So in order to continue to explore the topic of AboutOnlineMatters site latency, I need to cover that tool.  But then we get into the whole issue of the core set of site performance tools to use for evaluating site latency issues.  We already discussed and showed our results from pingdom’s latency analysis tool, but there are many more, some of them providing similar analysis and, as I was bemused to discover, often providing differing results for the same items.

So what I’ve decided to do is to provide some discussion of web site latency and performance tools and toolbars before we get back to analyzing AboutOnlineMatters, and then I can show how I used the tools to debug my site latency issues.

Here are the tools I plan to cover, and just so you know, I may cover some or all of them in flash/video, which would be a first for this blog.  Although I’m not a big video fan (I can take in more info more quickly by reading), I know many people prefer than format so I want to try and accomodate them along with my current readers.

It seems The Washington Post runs a regular feature called The Style Invitational in which it invites readers to change a single letter in words to create a non-existent new word and come up with a definition for the new version.  It also has a variant of the game where the reader is asked to give a humorous definition for an existing word.  They both produce hilarious results, but I’m going to focus on the former game.  Here’s an example:

ignoranus: An individual who is both stupid and an asshole
(Pardon the offensive language. I’m quoting it.)

These will have you bending over in laughter, but since we are in the SEO game, I thought it would be fun to see the exact match volumes from Google Adwords Keyword Tool.  It turns out “surprise! surprise!” that people actually search on these new terms.  So for all of the SEO experts in the room, you now have data to justify creating pages, content and tags for these words. The words are shown in the table below. By the way, I am in stitches that ‘bozone’ and ‘karmageddon’ are the two most searched for terms. Like, wow. I mean, like really? Dude, it’s as if some karmic word God has touched all humans with the ability to recognize the truly funny. Enjoy!