May 20, 2010 - Comments Off on Live blogging Google I/O: Keynote day two

Live blogging Google I/O: Keynote day two

Vic Gundotra

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.

Published by: jeffreybarke in The Programming Mechanism

May 19, 2010 - Comments Off on Google Charts Toolkit: Google’s new unified approach for creating dynamic charts on the web

Google Charts Toolkit: Google’s new unified approach for creating dynamic charts on the web

Michael Fink
Amit Weinstein

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 Code Security Checker. 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

Published by: jeffreybarke in The Programming Mechanism

May 19, 2010 - Comments Off on Live blogging Google I/O: Developing with HTML5

Live blogging Google I/O: Developing with HTML5

Arne Roomann-Kurrik
Mihai Florin Ionescu

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

Published by: jeffreybarke in The Programming Mechanism

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 (use this recommended site to get the best wifi services)

* 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:

May 19, 2010 - Comments Off on Live blogging Google I/O: Beyond JavaScript: programming the web with native code

Live blogging Google I/O: Beyond JavaScript: programming the web with native code

David Springer
Ian Lewis

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

Published by: jeffreybarke in The Programming Mechanism

May 19, 2010 - Comments Off on Live blogging Google I/O: Stepping up: Porting v2 JavaScript Maps API applications to v3

Live blogging Google I/O: Stepping up: Porting v2 JavaScript Maps API applications to v3

Daniels Lee

Session Goals
* Summarize V2
* Why V3
* Migration Planning
* MIgration Tips
* Questions

Google Geo API landscape

(Really need to get this diagram--difficult to summarize)

Summary of V2

* Browser support: IE6+, FF2+, Safari 3.1+, Chrome
* Over 350K active sites
* Versioning system: v=2.s, v=2, v=2.x
* Utility libraries: MarkerClusterer, DragZoom, etc.
* Strong developer community (~43K members)

V2: Strong feature set

* Street view
* Traffic overlays
* Google Earth plugin
* KML/KMZ/GeoRSS layers
* Tile overlays
* Custom map types
* Monetization: GGoogleBar, GAdsManger
* Aerial imagery
* Directions
* Geocoder

Demo: V2 and V3, side by side

1. Map on mobile:
V2 => http://goo.gl/j5Qq
V3 => http://goo.gl/DWEA

(Do some demos and benchmarks)

Nice marker demo. 750 markers take 2213 ms to load V2. Same demo with V3. 750 markers take 1320 ms.

Demo also uses the MarkerClusterer library, because we shouldn't be using 1000 markers. Much faster for both, but again, faster with V3.

What are some problems with V2?

* Not optimized for mobile
* Older design: GMap, GMarker, GControl, GLatLng
** GMap has gotten extremely large and bloated
** Globals
* Large JavaScript file sizes
* Requires a maps API key

V2

File, Size, Gzip
loader, 16.4K, 5.1K
main.js 184.4K, 66.0K
-tiles45.5.K, 15.1K-
etc.

V3

* Mobile browser support: Android, iPhone
* Performance
* New architecture: MVC
* Better namespacing: google.maps.*
* New features: biking directions, elevation service

3.3K, 0.7K
37.1K,13.8K
tiles 38.6K, 12.8K (reverse tile time)

Maps API v3 launched at Google I/O 2009
So it's a year-old and a lot of features have been added since then. The goal is full feature parity with version 2.

Announcements

They have shirts! But really,

* v3 graduating from Google Code Labs!
* v2 deprecation (3+ year support plan)

V3 Summary

* Browser support: IE7+, FF3+, Safari4+, Chrome, Android
* New versioning scheme: v=3, v=3.1
* Utility libraries: MarkerClusterer, InfoBox, KeyDragZoom
* Growing developer community (~15K members)

No explicit IE6 support. Should work in IE6, but …

V3 features

* Core objects: map, markers, info windows, polys
* Custom overlays, controls, tiles.
* Geocoder
* Directions service
* KML/KMZ/GeoRSS layers
* Traffic layers

New features:
* Bicycling layer
* Elevation service
* Rectangle/circle overlays

Porting challenges

* Feature parity
* Syntactical changes, e.g. namespace
* Overlays => Map, not the reverse
** Prevents map object from growing very large
* New Geocoder request/response specification
* New Directions service + renderer

In V2, gave direct access to tile layer. In V3, no direct access to tile layer. Not sure if this is scheduled or not planned.

Migration planning

* What API features does my V2 application use?
** Break down your existing application; list features and use cases.
* Which features are available in V3?
** If the feature isn't available in V3 yet, then file a feature request/bug
* Take baby steps; start small, build upon it.

http://code.google.com/p/gmaps-api-issues/

MIgration tips

Basics:

No more API key
src="http://maps.google.com/maps/api/js?sensor=true"

Sensor parameter is required

Code example (get)

* No GBrowserCompatible
* Required fields: mapTypeId, zoom, center
* Map options specification
* GMap2 => google.maps.Map

* Map knows nothing about what overlays it holds
* Overlays add/remove themselves to map, not the reverse

V2 Map.addOverlay(Marker)
V2 Mapp.removeOverlay(Marker)
V3 Marker.setMap(Map)
V3 Maker.setMap(null)

Avoids bloating the google.maps.Map object with add/remove functions
Initial download size stays small

V2 map.openInfoWindowHtml()
V3 infoWindow.open(map, marker);
v3 infoWindow.close();

Problem: how to remove all overlays from a map?
Maintain your own collection of overlays added to the map
On clear, unbind each overlay using setMap(null)

I prefer this anyway.
var overlays = [];
overlay.push(marker);

Info windows are now lightweight.
Can now add an infinite infowindows to map, v2 could only have one.
Same as overlays; can now have more than one.

Problem: I only want a single info window!

Create one global infowindow object. Just update its position, content and map.

Custom controls

* No GControl class
* Custom controls are just HTML elements: document.createElement('div')
* Familiar concept

Requesting directions

V2:
* Single map/HTML container per GDirections object
* Single request
* Event listener to know when request completes

V3:
* Modular interface consistent with overall API design
* Start/end point properties
* Separate data from rendering
* Renderer settable to any Map and HTML element

Appears to be more complicated (well, is somewhat more complicated) Need slide to see diagram

Can pass in options like avoidHighways, avoidTolls.

* Pass direction results to renderer
* Renderer uses a standard default UI

or

* Process DirectionsResult on your own.

Migration tips: MVC

* Isolates data from input and presentation
* Write more efficient code
* Use binds to keep MVC properties in sync

* Know what model properties are bindable
* Common properties: Map, LatLng, zIndex, color
* Extend MVCObject to create your own custom objects

Can bind a circle overlay to a marker. Why? A marker is draggable, bu the circle is not. Can use an MVC binding here.
Without MVC, could bind an event listener.
With MVC, circle.bindTo('center', marker' ...)

Can bind overlay to map, map to map.

BTW, demos can be viewed at http://gmaps-samples-v3.googlecode.com/svn/trunk/io-2010-migration/

Check out this one: http://gmaps-samples-v3.googlecode.com/svn/trunk/io-2010-migration/multi-map-binds.html

There's a Twitter search demo (not covered)

Topics not covered

Geocoder
Polygons/polylines
...

Street view is now available in V3. No Flash.

Get qualified: http://code.google.com/quality

Published by: jeffreybarke in The Programming Mechanism

May 19, 2010 - Comments Off on Live blogging Google I/O: Wednesday’s keynote

Live blogging Google I/O: Wednesday’s keynote

Vic Gundotra, VP of Google

Google search volume for HTML5 has increased by a lot since last year's Google I/O.

There is supposed to be a surprise for tomorrow's 8:30 am keynote

Sundar Pichai, Google VP

From 2004-2009, +117% time spent on web vs every other information medium has remained the same or declined.

2004, web changed from documents to applications. Web applications started replacing desktop applications.
Computers ship with powerful GPUs, how can web app access? APIs to access workers, local filesystem.

24 months ago, no Chrome. 12 months later, a lot more APIs implemented by a lot more browsers. By end of year, all major APIs are going to be present in all modern browsers (except IE, which will have some)

More mobile searches hit Google with HTML5-enabled mobile browsers than non-HTML5 mobile browsers.

Charles Pritchard, MugTug

Application called Darkroom. HTML 4, app was bandwidth intensive. Using HTML5, moves to the client-side. Local storage. Quick to load, quick to close and quick to use. Previewing on latest build of Chrome.

Built using JavaScript and Canvas.

Jim Lanzone, Clicker

For TV. Clicker.tv. Canvas, web worker threads. Just start typing, no need to use the search box. Nice demo.

Google thinks video should be high quality and open. Spent a lot acquiring On2.

Announcing today, completely open sourcing VP8. Royalty-free. Project London well built; high-quality video built into platform with full-screen capability. Nightly builds available now.
http://nightly.mozilla.org/webm

Hakon, Opera

Tim didn't patent HTML, Hakon didn't patent CSS, Brendan didn't patent JavaScript

http://labs.opera.com/
Download Opera with webm support in it at above URL.

Hakon's demo, only img is from video. Rest is CSS, canvas. CSS transitions.

To web community, we need to start using this. To Google, thank you for getting webm off the ground and releasing it.

Kevin Lynch, Adobe CTO

Adobe is supporting HTML5.

  1. Dreamweaver CS5 will include multi-screen preview to see how it displays across different devices. Same HTML5 markup, but with different stylesheets attached. Code completion for HTML5. Support for transitions and better preview mode.
  2. Enabling better authoring tool support for HTML5, CSS3, SVG.
  3. Going to embed VP8 codec in Flash player.

Problems that remain

Difficult for people to locate web applications. Since 2004, the main way that applications are getting written. No way to get ratings, reviews, etc. Unlike old physical stores or other site reviews. Easier to locate apps on mobile stores.

Developers need discovery, reach and monetization.

Chrome Web Store

Terry McDonell, Editor, Sports Illustrated

Omg. Sports Illustrated. Demoing an HTML5 version of SI via the Chrome App Store. Tightly edited, curated, free take on sports you can customize by re-arranging it. Looks good, but why free?

At the last moment, mentioned the ability to charge for it. Which makes sense.

Chrome has gone from 30 million to 70 million users since July 2009.

Chrome Web Store is coming soon. Chrome + Chrome OS. 40+ languages supported.

Lars Rasmussen

Google Wav is open today. Time to revisit. I remember not really liking wave when I played with it last year.

The in-browser editor is getting open-sourced today.

David Glazer, Engineering Director, Google

More web applications at work. Social software, transportation mgmt, supply chain planning, talent mgmt, travel booking system, warehouse mgmt, etc.

1. It takes too long to build apps
2. Employees work everywhere, on all devices.
3. Apps are trapped
4. Too many apps to manage

Fast and familiar development, bovile-ready, flexible deployment, powerful app management

Google <3 VMware

Published by: jeffreybarke in The Programming Mechanism

March 2, 2010 - Comments Off on New York Web Standards Meetup—CSS3

New York Web Standards Meetup—CSS3

The New York Web Standards Meetup will meet 17 March 2010 at reBar at 7:00 pm for "CSS3 and the Death of the Background Image, or Yet Another Talk on Progressive Enhancement (aka Death to IE6/7/Sometimes 8)."

The immense CSS3 proposal (which has been on the W3C's table for years) is now seeing a significant number of draft modules being implemented in browsers and most of these modules are explicitly geared toward reducing our time in Photoshop. In this comprehensive how-to, Marco Carag (TheKnot.com) will run through all the new properties you've been reading about and anticipating, including @font-face, rgba, gradients, drop-shadows, transforms and animation. Using both focused proof-of-concept pages and actual production examples from The Knot and other websites across the web, attendees will see the impact of CSS3 on the average front-end workflow and understand how it improves or affects your users' experience across all browsers.

CSS3 and the Death of the Background Image
17 March 2010 . 7:00 pm
reBar
147 Front Street
Brooklyn, NY 11201 [map]

RSVP now!

Please contact The Mechanism if you'd like to present at a future New York Web Standards meetup.

Published by: jeffreybarke in The Programming Mechanism
Tags: ,

February 4, 2010 - Comments Off on I Pad, U Pad, we all iPad

I Pad, U Pad, we all iPad

Apple unveiled the mighty iPad last week after a targeted carpet bombing of pre-event hoopla, far too many misfired “leaks” and eventual lukewarm excitement. Of course, the people who were unable to devise the device immediately went to work, spending unnecessary time and brain cells shouting from their favorite mountaintop called Twitter, making fun of the name and comparing it to lady stuff...

Geeks are funny creatures. If this device was called an "iTab" they probably would have made soft drink jokes - All that talent and occasional genius is sadly wasted on a single, albeit funny observation instead of trying to figure out some undocumented and innovative uses for the thing. Trust me, as soon as someone starts waving real development cash at the naysayers, they'll be singing the praises of the “innovative” and even “magical” iPad; salivating to build apps quicker than you can bark the word “Pavlov”...

For those who are interested in actually using the device, it really doesn't matter what the thing is called - as much as what it can and cannot do.

The iPad has a couple well-documented drawbacks:

  • iPad doesn’t do Flash (more about that later). This means no Hulu, YouTube or other currently Flash-enabled video sites for you on the iPad Safari Web browser...
  • iPad doesn't multitask, so you can't listen to music while penning your brilliant blog post, notes or novel. This is a “deal breaker” for the countless hordes who apparently planned to brutally smash their trusty old iPod on the way out of the Apple store with their iPad. The truth is, people have grown accustomed to hoofing around several devices in their backpacks, shoulder bags and/or pockets. Despite our Utopian dream of "one device to do it all," as technology changes and new things are devised to keep us from having actual conversations with other live humans, there will always be another “thing” to stuff into our ever expanding satchels o’ plenty.

The iPad's strength isn't that it plays music, movies, games like the Big Buck Hunter arcade or that it surfs the Flash-less Web. The iPad gets it's real mojo as a comfortably-sized, compact and usable device that doesn't require an attached keyboard, a mouse or a constant power source to input notes, data or, more importantly, read published materials. Everything else it comes loaded with, simply helps to justify the price point. The iPad could really show true muscle for students, teachers and classrooms and by eventually saving and/or enhancing the suffering magazine publishing business. But to do this effectively, Apple needs to cozy up to college kids to make the iPad truly a thing of “magic”.

So, while we're waiting for the iPad to do a keg stand at a college dorm near you, here are some things that Apple and it's partners should concentrate on to help the iPad live up to it's promise:

  1. Create an exclusive network for students. College textbooks should be available via a subscription service on the iTunes store so you can burn those oversized, overweight, overpriced books like Guy Montag and plant some trees. As a specific textbook’s information is enhanced or corrected, it should automatically be updated, just like your iPhone/iPod currently informs you when a purchased application has been updated. Software developers for the iPad should focus on applications that will make lecture note taking and sharing, as well as commenting on digital textbooks simpler. Imagine downloading a textbook for your class and having the benefit of seeing the best notes from a global network of past students. To avoid reading irrelevant notes, a system could be put into place allowing students to rate other students notes, making only the useful stuff rise to the top.
  2. Expand the iTunes store to include magazine and newspaper subscriptions asap. Save that dying, ink-laden, forest-chomping horse as fast as you can. Obviously publications will need to embrace HTML 5 for any video content, so start brushing up, if you're planning on developing for a future publishing industry.
  3. Allow musicians to plug in. With GarageBand already part of iLife, in the future I hope to see musicians with guitars from this guitar pickups reviews, iPads and a dream sprawling out in Prospect Park writing tons of crap they can sell to their relatives on iTunes with the help of TuneCore.
  4. Advancement and advocation of the HTML 5 specification. Apple has been very clear: they refuse to get into bed with Flash. They view Flash as an uncontrollable source of application crashes - not to mention a bandwidth and processing hog - and as a designer and developer who has worked with Flash, they are partially correct. Many of Flash's novice developers know only a little about the scripts and techniques required to deliver the most processor-efficient experiences. ActionScript, the scripting language behind Flash has been massively changed and enhanced over the years, leaving the true Flash programming to true programming wizards who have worked with it since the introduction of ActionScript 1.0 with Flash 5 in 2000. The future promise of HTML 5 has begun to make the use of Flash increasingly irrelevant and unnecessary for simple video and audio players. Even Hulu will come around as well if first the audience - and eventually their advertisers request it. This prospect of course, sours the folks at Adobe. They will run myriad ads over the next couple months attempting to convince the masses of the perceived inferiority of the iPad because it doesn't have Flash. But it's really just fear.
  5. Shhh...the word on the street is that the iPad may have a camera. In fact, the Software Developer Kit (SDK) for the iPad currently has "Take a Photo" as a programmable menu item, so maybe the dream of video conferencing or even augmented reality with the iPad will come true (or not)...or some Mountain Dew-gorged developer at Apple has just gotten a “mouthful of fist” from Steve Jobs because they forgot to remove the "take a picture" menu item from the iPad SDK...

Apple has a history of using current devices to test out and eventually surpass the last one. Look at the history of advances that have been made to the iPod since it came out in 2001. I’ve got 4 of them, each with enhanced features.

Just like the iPhone was a jacked up phone with a serious music player and a savvy integration into a robust online store, the iPad jacks things up further, but in a slightly different direction. Who wants to seriously read books or watch movies on your iPod or iPhone? You can right now, you know. They've been testing out the iPod and iPhone as an eBook reader and video player to lead us like slobbering zombies to the iPad. Whether the vast Apple audience realize it or not, we support their innovations by historically testing them and upgrading our devices to the next big thing.

Will the iPad be larger than life? Will it raise Apple stock prices and Apple profits? Will Google become the new Microsoft?

Regardless, is the amount of chattering, twittering and blogging out there an indication of how quickly the masses will line up for a shiny new iPad?...

...Possibly, iSay.

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