Overview

* Recap: What’s in HTML5
* What’s happened since I/O 2009?
** Lessons learned
** New APIs
* What’s next?

What is meant by HTML5

* It’s a buzzword
* Spec has shed numerous features
* Storage specs are now separate
* File specs and others live in WebApps, DAP
* Geolocation
* WebGL

Many things were split out for convenience; too many things for a single working group

Areas we are excited by

* We’ve spent the past year on …
** Offline (Appcache, Storage)
** Media (Video, Audio, …)
** Networking (Web Sockets)
** CSS3, Paged Media, Layout
** Platform integration (Drag and Drop, Notifications, Geolocation, …)
* Focus is providing richer experience for web applications

What we've learned

Offline Apps

* Discovery and re-discovery
** Remembering to type in exact URL is difficult
** Many people don’t use bookmarks
** Web Store helps discovery and re-discovery
* Packaging as an “app” can bootstrap permissions that need to be granted before use.

Indexed Database API

* “Specability” concerns around SQL
* A simple database, no SQL
* Has a “key” (DOMString or long) and associated “value” (object, array, …)

In the process of implementing a ??? DB, but no browser yet implements it. Why not SQL!

Storing Files

* Currently implemented storage APIs (Local Storage, Session Storage, WebSQLDB) don’t meet all the use cases
* Storing binary data in Local Storage, Database can have severe performance implications
* Need to be able to treat data as a file
* Filesystem API (and FileReader, FileWriter) gives web applications a sandboxed, per-origin filesystem

Geolocation (aka “Security UI is hard”)

* Access the user’s location via a JavaScript API
* Accuracy varies based on device
* Permission model varies for embedded content (iframes)

Tied permission not to origin of JavaScript, but to top URL (for iframes and embedded maps.google.com)

Shared State between Pages

* Shared worker
** Standard, cross-browser
** Works well for apps designed around message passing
** No single script context
** Can’t pass around parts of the DOM
** Example: Controlling access to shared File System API resources from multiple tabs

* Magic iFrame
** Can pass around parts of the DOM
** Can share scripting contexts
** Example: Gmail window tearoffs

Dragging files on the web is a drag

* Intuitive, simple ways to upload, download files
* Drag-in: desktop to browser
** Listen to drop event
** Obtain File object, send via XHR
* Drag-out: browser to desktop
** DownloadURL format in DataTransfer object
** Contains file type, name, URL

Notifications

* Let the app notify the user in an unobtrusive manner
* Developer can provide HTML or plain text content
* Permission is assigned on origin basis
* Currently two specs:
** http://dev.w3.org/2006/webapi/WebNotifications/publish/
** http://www.chromium.org/developers/design-documents/desktop-notifications
* Plan to deprecate the latter in favor of the former

What’s over the horizon

TTS (text-to-speech) and voice recognition

* Voice is the hot new thing in mobile
* Let a web app accept voice commands and input
* Speak results to the user

Webcam/microphone access

* Laptops and phones today ship with integrated webcams, microphones
* Many use cases for accessing these devices:
** Videoconferencing
** Taking a picture (profile pics)
** Scanning barcodes
** Letting the world hear you sing a Lady Gaga song
* Looking to expose APIs that let you capture a single blob and a s stream

[Wow, this is a win]

Positional Audio

* Adding JS apis for enhanced audio

Web GL

* JS bindings to OpenGL
* Allows creation of 3D games in the web
* Pioneered by Firefox, now being implemented in Google Chrome, Apple Safari and more

What you will get from this talk

* How performance affects your site
* Become familiar with page speed
* Learn about four new product features
** Page Speed exports
** Page Speed SDK
** Apache module
** Page Speed for ads, analytics

Web performance 101

* Speed = eyeballs

A bunch of numbers from O'Reilly Velocity Conference, May 2009

Building Blocks

Processing time at the web server

Bandwidth and round-trip time on the network

Parse, resource fetches, layout and render and JavaScript on the client

Example page load

Client
DNS lookup
TCP connect
HTTP request ->

Server
Server processing <-

Client
Parse & layout
Subrequests ->

Three speed guidelines

* Serve fewer bytes
** Compress at serving
** Optimize images
** Minify HTML, JS, CSS
** Cache aggressively: fastest serving is when you don’t have to (including pre-caching)
* Parallelize resource downloads
** Optimize the order of styles and scripts (more late)
* Promote modern browsers

New and improved optimization rules

Minimize request size (including length of URL and size of cookie. Trying to fit in a single or as few TCP packets as possible). Particularly important for mobile.

Specify cache validator (need to learn more about this)

Specify character set early. Why? Otherwise browser guesses by buffering content and guessing the charset.

New features: the beacon, export to ShowSlow

Page Speed SDK

* Initially Page Speed was implemented in JavaScript, tightly coupled to Firefox
* Ported Page Speed rules to browser independent C++ library
* Recently released as a C++ SDK
* Download: http://bit.ly/cwx7JX

gomez: tool to be release soon. Looked like an app.
HAR to Page Speed (HAR? A new JSON format to transport info about page load speed) Steve Souders

har_to_pagespeed command line tool included in the Page Speed SDK
Reads a HAR file, emits Page Speed results

mod_pagespeed

Very early in the lifecycle for this product.

An attempt to not tell developers how to speed up their website, but would actually implement it for them.

Automatically optimize things for you.
* Minify HTML, JavaScript, CSS, images
* Content rewriting to reduce serialization
* Portable rewriting engine that can be re-used in other environments
* Open source, under development: http://code.google.com/p/page-speed/

Looks interesting, but possibly dangerous. Would rather do this at build, not at run-time.

Using MD5 for URL fingerprinting seems like a brilliant idea, though. Again, would rather do it at build time.

Looking at ads and trackers

Filter option to analyze ads only, analyze trackers only, analyze content only or analyze the entire page.

Possible future rules under evaluation

Use chunked encoding

* Dynamic responses can be expensive to compute
* But boilerplate header is usually static
* Send header chunk first, then dynamic body later
* Allows browser to begin fetching external JS and CSS sooner
* Big wins for Google properties such as Search and Calendar

Definitely need to learn more about this (will this work with JS declared near the end of the body or would this be a case to move it back to the head)

Minimize the size of early loaded resources

* Modern browsers are much more efficient when fetching resources declared in HTML
* But JS and CSS in the head still blocks the renderer!
* Users stare at a blank screen until these resources are finished being fetched, parsed and executed.
* Load only the minimal JS and CSS
* Use Page Speed “Remove unused CSS” and “defer JS”

Minimize fetches from JavaScript

[This is interesting.]
Modern browsers use speculative fetching to fetch JS resources in parallel.
Speculative fetcher only parse HTML.
Resources fetched using JavaScript are still serialized.

Page Speed for Chrome: There will be a Chrome extension integrated with Chrome Developer Tools coming later this year.

code.google.com/speed/page-speed/

http://code.google.com/p/page-speed/

http://groups.google.com/group/page-speed-discuss

A review of sites submitted for SEO critique.

Schmitties! Google does not index meta name="keywords"

The page needs text. If you don’t/can’t do it yourself, try user-generated content.

WordPress love, but keep it current. Even use .htaccess to limit IP address access to wp-admin.

Try to get content above the fold; not critical, but better.

Add more content to the title tag (from the meta name="description")

[Matt Cutts is hilarious. This is probably the most enjoyable session I've attended yet.]

One of the review sites was hacked.

Don’t expect to rank high if all you do is syndicate other people’s content.

Look for blog post on local business SEO. Google places. (Recent blog post by one of the panelists. Ex-Google)
Vanessa.

http://ninebyblue.com/

Related content is win

Don’t really want search ranking, you want traffic. And don’t really want traffic, want conversions.

If everything else on your site is pretty good and the URLs are bad, not that big of a deal. If you can get descriptive URLs, win. If not, no big deal.

Get the full address on there so Google can associate the site with a location.

Make sure internal URLs are singular or else use rel=”canonical”

#! is a way to help Ajax get crawled. Search “crawl Ajax” Definitely need to learn more about that.

Mayday is an algorithmic change in Google (should find out more about this).

http://searchengineland.com/analysis-which-url-shortening-service-should-you-use-17204

Yesterday’s keynote recap

* HTML5
* Web apps
* Chrome web store

Two perspectives on web apps

* Users: How can I get better web apps?
* Developers: How do I make money doing this?

From a user perspective, web apps can be difficult to find. Awareness.

No authoritative place for web apps. Web apps may contain a lot of contain, but generally doesn’t contain content that can be crawled and indexed in the standard way.

The cheaper the purchase is, the more the trust and convenience issues get in the way.

Web apps are special to users, but the browser treats it like any other page.

Web apps don’t have a shortcut to launch them, don’t have deep OS integration. Etc.

Security model of browser is good, because able to trust most links. Part of model enforces limited capabilities. There are times we’d like the web app to do more, but no way to indicate this trust.

Web store link will be integrated tightly with the Chrome. Link always there.

Apps launched from the apps tab will display differently. Address bar hidden (to make the app central). The actual app tab will be smaller, but the favicon will be larger. Trying to treat the app as a first-class citizen.

How to monetize web apps

If costs are high and traffic is low, you don’t get to set the price, it sets itself.

Need to integrate with payment processors.
In order to attract the most users, must target the least capable browser.

Web store wants to handle licensing and payment for you. Web is not a captive audience–not like the other phone app stores.

Pushing us to just use Chrome (???) and the Chrome web store. A lot of users on Chrome. Explicitly said, "We don’t need to target the lowest browser anymore." Interesting (especially since the web app is available on the web) and a lot of these features aren’t even supported in Firefox. Reminds me a lot of what Gears promised two years ago (and never delivered). And then it was gone.

Any app can go in the web store (HTML, Flash).

Can add a JSON manifest and icons for packaging to the store.
Can add permissions at install time to remove some of the browser’s security model!
Can add permissions property to JSON manifest (array of required permissions).

If user trusts and installs the app, then will not be constantly prompted by the browser.

Installation similar to an extension.

Google Maps added geolocation support for select browers. (hadn’t noticed this before)

Action items

* FAQ: http://chrome.google.com/webstore
* Docs: http://code.google.com/chrome/apps
* Build a really cool web app
* Join the discussions

Developer preview this summer and then open to public in the fall.

First time GA has done anything at Google I/O.

Four components
* Processing
* Management
* Data collection
* Data exporting

Core processing

Dimensions: Strings (80 dimensions)
Metrics: Numeric values (95 metrics)

1. Logs (collection)
2. Goals, filters, profile settings (management)
3. Data structure (processing)
4. Functions (processing)
5. Tables (processing)
6. Query engine (export)

Core visitor interaction model

Visitor/session/hit levels

1×1 tracking pixel with a number of parameters appended. Three of these parameters relate to visitor, session, hits.

Their back end parses their logs and sorts and stores based on parameters.

ga:visits

int visits(Session session, int index) {
}
[Too quick to get these code snippets]

Developer platform

Data types (several)
Protocol (_utm.gif)
Client libraries:
* JavaScript (ga.js)
* Android SDK
* iPhone SDK
* Mobile websites
** PHP/JSP/ASP/Perl
* ActionScript 3
** Flash/Flex/Air
* Silverlight

Account Management

Data types:
* Accounts
* Web properties
* Profiles
* Goals
* Advanced segments

Protocol:
* Google data

Data export API

Protocol: Google Data
Client libraries:
* Java
* JavaScript
* Python
* .Net (C#)
* Ruby
* Perl
* PHP

Use the Data feed query explorer (in Google Labs)

Example integration

Using visitor behavior to optimize user experience: ranking a number

Start with a list of unordered links. Can use GA to track the number of times people click on these links.

Demo is powered by MAMP; hopefully the code will be made available. (Definitely need this code)
Two parts to the demo:
1. How to send data explicitly to GA
2. How to retrieve data from GA

Part one was implemented with PHP and JS
Part two is a scheduled .Java application

Recently introduced asynchronous tracking (to avoid blocking the browser).

Working on a better developer ecosystem:

http://google.com/analytics/apps

Working on a better turn-around time than 24-hours.

Working on complete data export, but difficult because they store it as a cube. The current export API is actually more of a query API.

Opens with an anecdote of how he got involved with Android at Google.

In 18 months, 60 compatible devices. Q408 to Q210.
21 OEMs, 48 countries, 59 carriers.

A review of the accomplishments/adoption numbers of Android.

50,000 applications in the Android marketplace.

5x growth in mobile search ‘08-’10 (all phones)

Android 2.2 Froyo announced. JiT compiler. 2x-5x speed up in applications.

Microsoft Exchange friendly:
* auto-discovery
* security policies
* GAL lookup

New SDK features:

Application Data Backup API
Cloud-to-device messaging API (this is impressive)
** From desktop, driving directions sent to phone. Phone picks up message not as text, but as “intent,” immediately launches navigation application.

Tethering & portable hotspot

The Froyo browser has a 2x-3x increase in JS performance. Doing laps around Eclair and the iPad.

Amazing voice recognition capabilities! Voice input will be a first-class means of interacting with Android.

Android will support Flash and AIR. Digs at Apple.

Improvements to marketplace:
* Easier to search/find apps
* Search inside apps
* Move to SD cards
* Allow automatic updating

Application error reports: on crash user can send error report to the application developer.
Developers can see the entire stack-trace of what happened.

Can search the marketplace via the PC. If logged in and purchase an app, app will be sent to device instead of having to tether and sync device with PC.

http://code.google.com/apis/charttools/

First demo: http://www.xefer.com/twitter/

Google Chart Tools

Mission: Make the world’s structured data universally accessible & useful by providing enticing visualizations.

1. Image charts: server side rendering
2. Interactive charts: Client side interactivity
3. Under the hood
4. Combining server side rendering with client side interactivity

Image charts

The Google Chart API. The URL contains the parameters of the chart you wish to receive.

Launched a chart editor yesterday:

http://imagecharteditor.appspot.com

Started out with charts, but realized there’s a lot of rendering needs they could meet in the same way.
* Math
* QR codes
* Dynamic icons
* Flags

Interactive charts

Hundreds or thousands of hours spent developing charts in-house for Google needs. Decided to give back to community.

The interactive chart gallery is really a community effort.

* New look and feel for interactive charts (launched yesterday)
** Color palette
** Layout (negative vs positive space)
* New chart combinations to be released in the next few weeks

Demo site: BackPaki

Wiki page for backpackers.

http://code.google.com/apis/ajax/playground/

Nice integration of interactive chart with the Google Maps API.

[Review the code snippet]
goog.bind(function(e) {
this.stack.push(e.region);
});

Google Charts defines data table. Can use a query to bind the visualization to a Google spreadsheet.

The remote data sources provided by Google can be a Google spreadsheet, Java library or Python. Users can use a PHP or Ruby on Rails.

Using the Google API, can convert your data to XML and then use the WP_Cumulus plugin (Flash-based).

Comparison:

Image charts
* Static image
* URL access
* <1s

Interactive charts
* Interactive experience
* Data remains on client
* Basic JavaScript
* Data manipulation functions

In past year, wanted to combine the two efforts: server-side rendering with client-side interactivity.

Interactive GraphViz

When making request to server, receiving two things: a static image as well as the layout. That static image makes use of server-side rendering and caching, while the layout permits client-side interactivity.

Google Chart Tools

1. Rich gallery
2. Free of charge
3. Highly customizable
4. Interactive playground
5. Active developer group
6. Live data from many sources
7. Easy to adopt and simple to use
8. Detailed documentation and examples

http://bit.ly/html5-io2010

Presentation built with HTML5.

Agenda

* The road to HTML5
* HTML5 and Google Chrome
* HTML5 primer and building an HTML5 application
* Demos
* Key take-aways
* Developer resources
* Q&A

1990: First webpage
1994: HTML 2
1995: JavaScript
1995: CSS1
1997: HTML4
1998: CSS 2
1999: XMLHTTP
2002: XmlHttpRequest
2005: Ajax
2009: HTML5

Google Chrome: Where are we now?

* 70+ million users
* 28 stable releases or updates
* 300% JavaScript performance improvement
* HTML5 support for web application development

Demo: Chromabrush

Check out http://chromabrush.com/

* The canvas element: Low level control over rendering (really need to do some work with canvas)
* Multimedia: audio and video (point to webm video)
* Worker threads to avoid browser blocking (definitely need to learn more about this)
* Desktop experience (drag and drop)

Notifications are currently exclusive to Chrome.

http://code.google.com/apis/webfonts/

Nice real world demo of thumbplay music. Not sure if this demo is live yet or if it’s an internal beta for them. Possibly. Drag and drop is done using jQuery, since native drag and drop isn’t ready for prime-time yet.

New, HTML5-enabled TweetDeck demo. An internal piece of research. Wasn’t sure if it was possible.

* HTML5 gaining momentum
* Browser innovation accelerating
* Parity with desktop apps
* Developer community participation essential

Write once, run anywhere

* Mobile is hot
* Desktop is still hote
* Save development time

Agenda

* Overview of Geo APIs
* Different options for mobile
* UI considerations
* Geolocation
* Real world app

Options for Google Maps on Mobile

* Maps API V3 in browser
* iPhone native MapKit
* Android native MapView
* Hybrid native with browser
* Static Maps API

[Need chart for comparison] V3 is the clear winner.

And now street view:
* HTML5 canvas 2D
* HTML 4
* WebGL

WebGL has the best performance.

Easy to add street view to the map: map.setOptions({ streetViewControl: true });

Browser based maps

* Full JavaScript browsers
* Access to some phone features
* HTML5
* Write once
* Rapid development
* No App Store/Marketplace process
* No App Store/Marketplace discoverability

Native APIs

MapKit on iPhone
MapView on Android
App Store/Marketplace discoverability
* App Store/Marketplace launch process
* Slight performance increase
* Harder development
* No support outside of platform

Hybrid native apps with embedded browser

WebView on Andorid
uiWebView in iPhone
Access to additional features of phone
Rapid development of map
Map is write once, but app is write per platform

Static Maps API

* Any browser
* Lightweight and fast
* No features of modern APIs
* Write once, run anywhere
** and really, anywhere

UI considerations

* Size of screen layout
** Make your <div>s flexible
** Vary your chrome by browser or screen size
* Touch events
* Native vs browser look and feel
** iUi

Geolocation

* HTML5
** Device provides location
** Mobile often gives GPS location
** Desktop browser gives IP or wifi

* IP-based
** IP lookup
** Coarse
** Google Ajax API ClientLocation (or other provider)

[Demo of HTML5 geolocation]

Campus Map demo

* Wide variety of audiences using maps
* Visitors and guests will visit the web site
* Frequent users prefer the convenience of an application
* Only enough resources to maintain one code base

* Shared datasets with version 2 map
* Early on- lack of features
* User interface with small, touch-based screen

Hybrid application

* Performance concerns (with proper optimizations, not a great concern)
* It felt like "cheating"

Optimizations

* Use KML layers for complicated data (for panning)
* Compress JavaScript (Closure-Compiler)
* Delay loading the maps API so as not to block page rendering (use the boot loader and then dynamically add script tag to page)
* Use Google page speed

View uncompressed source of University of Missouri campus map

Q:
A: Pinch-to-zoom only works on the iPhone, because that’s the only browser that exposes those events to JavaScript.

http://en.wikipedia.org/wiki/Google_Native_Client

http://code.google.com/p/nativeclient/

Agenda

[]

Non-agenda

* Internals and technical details
* Security model

Talked about this last year.

Native Client = NaCl (na-kkle)

Overview: What is NaCl

* A portable system for verifying and executing untrusted native code in the browser.
** High performance like C++
** Safe and portable like JS
* A runtime sandbox
** “Virtual Mini-POSIX”
** Standard operating system services
*** Kernel (Chrome)
*** Window manager
*** Media layer (Pepper)
** Identical on every supported platform (Mac, Windows, Linux)

NaCl: What is it good for?

* Port desktop applications to the web
** Zero install
** Native performance
* Enchance web apps with…
** Existing C/C++ libraries (libcrypt, CGAL, etc)
** New high-performance compiled code
* Sandbox existing plugin code
** Stop asking users to trust your code

Lunch ain’t free

* Must compile verifiable code
** Minor performance penalty
** Generally large executables
* Some *nix syscalls are unavailable
** Process creation
** Direct network/file access
* Still some rough edges

How does this make my life better?

* Native performance
* Platform-independent multimedia
* Your choice of language
* Low-level system services
* The end of: The “do you trust this publisher” confirm installation box. Asks user to make an impossible choice.

Demo: unity

Unity game Lego Starwars. Four guys ported game in four weeks. Not super difficult thing to do.

The NaCl SDK

SDK goodies

* C/C++ toolchain
* Standard GNU libraries
* “Pepper”
** NPAPI-like interface
** Audio/video
** OpenGL ES 2.0
* JavaScript interop
* Sample code and build scripts

Using the SDK

* Build with standard GNU toolchain
* Run in web browser
** Server required
* Debug with GDB-compatible debugger
** via GDB stub

Demo

Anatomy of a NaCl application

(Diagram)

1. Install the SDK
2. Organize project directories and files:
   • application
   • nacl
   • c_salt

The HTML and CSS is straightforward.

Coming attractions

* Full debugger support
** GDB
** Visual Studio
* IDE plugins
** Eclipse
** Visual Studio
** Xcode
* Easy to use interop library
* P-NaCl (portable NaCl) (pinnacle)

nativeclient.googlecode.com
nativeclient-sdk.google.com.com
native-client-discuss@google.com