All Posts in google-io

June 17, 2013 - Comments Off on Cognitive Science and Design

Cognitive Science and Design

This session will provide an in-depth look at human perception and cognition, and its implications for interactive and visual design. The human brain is purely treated as an information processing machine, and we will teach the audience its attributes, its advantages, its limitations, and generally how to hack it. While the content will provide a deep review of recent cognitive science research, everything presented will also be grounded in example design work taken from a range of Google applications and platforms. Specific topics will include: edge detection, gestalt laws of grouping, peripheral vision, geons and object recognition, facial recognition, color deficiencies, change blindness, flow, attention, cognitive load balancing, and the perception of time.

via Cognitive Science and Design — Google I/O 2013.

From this year's Google I/O conference. Well worth the 35 minutes.

 

Published by: antonioortiz in The Thinking Mechanism
Tags: , , ,

May 20, 2010 - Comments Off on Live blogging Google I/O: Google Analytics APIs: End to end

Live blogging Google I/O: Google Analytics APIs: End to end

Nick Mihailovski

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

1x1 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.

Published by: jeffreybarke in The Programming Mechanism
Tags: ,

May 19, 2010 - Comments Off on Live blogging Google I/O: Map once, map anywhere: Developing geospatial applications for both desktop and mobile

Live blogging Google I/O: Map once, map anywhere: Developing geospatial applications for both desktop and mobile

Mano Marks
Chad Killingsworth

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.

Published by: jeffreybarke in The Programming Mechanism
Tags:

July 25, 2008 - 2 comments

NY Web Standards Meetup—Review of Google I/O

Review of Google I/O at the New York Web Standards Meetup Group 24 July 2008 Notes and links from last night's Google I/O review at the New York Web Standards Meetup Group. Thanks to everyone who made it!

Note—There's a "curated" selection of Google I/O videos posted on my blog at http://jeffreybarke.net/tag/io2008/.

PowerPoint presentation

Demos/tutorials

Jeffrey Barke is senior developer and information architect at theMechanism, a multimedia firm with offices in New York, London and Durban, South Africa.

Published by: jeffreybarke in The Programming Mechanism
Tags: , ,

July 21, 2008 - Comments Off on NY Web Standards Meetup—Review of Google I/O

NY Web Standards Meetup—Review of Google I/O

The New York Web Standards Meetup Group will meet this Thursday (24 July 2008) at theMechanism at 7:00 pm.

Google I/O was a two day developer gathering in San Francisco, 28–28 May 2008, which covered building the next generation of Web applications with Google and open technologies.

Jeffrey Barke, senior developer and information architect at theMechanism - New York, attended and will talk about what he learned there, specifically focusing on Gears, Google App Engine and the Google Ajax APIs. Prior to the meetup, you can read a bit about his experience here and watch some of the videos he's gathered at JeffreyBarke.net.

24 July 2008 . 7:00 pm
theMechanism
440 9th Avenue 8th Floor
New York, NY 10001 [map]

RSVP now!

Please contact us if you'd like to present at the September or October meetup.

Jeffrey Barke is senior developer and information architect at theMechanism, a multimedia firm with offices in New York, London and Durban, South Africa.

Published by: jeffreybarke in The Programming Mechanism
Tags: , ,