Pundits of all types have been predicting the end of the iPad’s dominance since it was launched in April of 2010. Fortunately for Apple, and Apple investors, the enemy hasn’t been able to muster a proper offensive yet. Will Amazon’s Kindle Tablet finally end the iPad’s dominance over the burgeoning tablet computing market?

The tablet computing market is worth a lot, and it’s growing fast. In Q2 2011 15.1 million tablets were shipped, that’s a 300% increase over what was shipped in Q2 2010. Units shipped were up 88.9% from Q1 to Q2. IDC is now expecting shipments of nearly 65 million units in 2011.

Apple holds the majority of the market at 68.3%, up from 65.7% in Q1 2011 according to research firm IDC. As of June, Apple had already shipped 28.73 million iPads. Apple is expected to sell nearly 55 million iPads in 2011, and that number is expected to more than double in 2012. Their Q2 2011 market share is down from from the 87.4% they commanded in Q3 2010, but they were pretty much the only game in town in 2010. Android based tablets, RIM’s PlayBook, and Hewlett Packard’s TouchPad are duking it out for what’s left of the market. Amazon’s Kindle, and other e-readers, aren’t considered to be true tablets, so they aren’t included. However, Amazon’s readying their own horse for the tablet race that’s likely going to give Apple a run for their money.

We started hearing rumors of an Amazon Kindle Tablet back in September of last year, around about the time Amazon was getting ready to launch the Amazon Appstore for Android. Then in September, TechCrunch published a story that included a rundown of the hardware and software feature set. Apparently, they got their hands on a DVT (Design Verification Testing) unit. None of this was confirmed by Amazon, so it’s all rumor at this point - though the source is apparently strong. Below, I’ve included some of the specific hardware and software features that were revealed in the story.

Amazon Kindle Tablet DVT

Hardware

• think BlackBerry Playbook
• 7-inch display
• single-core processor
• minimal storage, it relies heavily on the Amazon cloud for media storage
• no camera
• wi-fi only
• rubberized back

Software

• based on a forked version of Android OS, apparently a version older than 2.2
• you won’t see any of Google’s Apps, or the Android Market here, it’s all Amazon
• The music player is Amazon’s Cloud Player. The movie player is Amazon’s Instant Video player. The app store is Amazon’s Android Appstore.
• the user interface is Apple Cover Flow-like
• apparently the user interface is “very responsive”
• in portrait mode, it has a dock where users can add their favorites
• the reader app is a lot like iBooks and the Android Kindle app

There isn’t anything impressive, or innovative about the Kindle Tablet from a hardware point of view. It doesn’t compare to an iPad 2, it isn’t even a fair race.  It is however a lot more interesting from a software point of view. The Kindle Tablet, or more importantly Kindle OS, is optimized for people that subscribe to the Amazon experience. Storage on the device is rumored to be minimal, so you’ll have to rely on Amazon’s Cloud for storage. Other media interfaces, books and movies for example, will also be optimized for Amazon services. It’s even rumored that the device will come with a free membership to Amazon Prime - a members only service that includes free 2-day shipping on eligible items and access to a growing library streaming video content.

The fact that all of these services are integrated into the experience is great if you’ve bought into the Amazon ecosystem, but it might come off as restrictive to someone that pulls media from a diversified set of services. Will tightly coupling the Kindle Tablet user interface with Amazon’s services infrastructure handicap the tablet out of the gate? We’ll see. You could argue that their approach isn’t all that different from Apple’s. The iPad after all partially owes it’s success to the curated experience provided by the iTunes ecosystem. Apple’s iTunes success is definitely tied to the fact that iTunes is tightly coupled with Apple’s hardware line. This tight coupling between hardware, software, and services is part of the motivation behind Google’s acquisition of Motorolla Mobility for $12.5 billion dollars - they want to have more control over the whole experience. It’s starting to look less like a device vs. device battle, and more like an ecosystem vs. ecosystem battle.

The iPad vs. Kindle Tablet decision for a lot of people will come down to price. The thing that caught my attention in the TechCruch article was the price-point for the Kindle Tablet - $250. A sweet-spot, I think, at half the price of the low-end iPad 2 and RIMM’s PlayBook. The delta in price is definitely enough to make most consumers think twice about iPad vs. Kindle Tablet. And… Amazon has the marketing muscle to make sure everyone knows they have other options. Price, is the Kindle Tablet’s real competitive advantage. Apple is strong on all the other fronts.

It’s really premature to predict whether or not the Kindle Tablet has a chance at ending the iPad’s dominance over the tablet computing market. The price difference is going to be a big factor for a lot of consumers. You can get get two Kindle Tablets for the price of a single iPad. I also think we’re headed towards a future where the software, and services ecosystem supported by the device is more important than the device itself. More than ever, it’s less about the hardware and more about the software, and access to services that in can provide.

– Cale Bruckner

However, when working with GWT, you quickly find that the toolkit’s implementation of the Java API’s are incomplete, and that using types that Google hasn’t provided as translatable will result in a GWT compiler error.

We wanted to be able to use the java.net.URI and java.util.UUID classes in our client-side code, neither of which are supported by GWT. This tutorial describes a method for implementing client-side versions of JDK classes that GWT doesn’t support. Fortunately, GWT provides support for overriding one package implementation with another.

There have been some attempts to implement more of the JDK; for example see GWTx, but they are quite incomplete.

It is extremely useful, then, to have a clear technique for creating client-side versions of some JDK classes that are unavailable. GWT helpfully provides a mechanism for doing this (look down under “Overriding one package implementation with another”), but doesn’t tell you much about how to use it.

I went looking for some examples of how to use the “super-source” XML tag to create some client-side implementations of some java types, and found a couple of incomplete or confusing tutorials:

• * Summary of Some of the Pecularities Involving GWT Eclipse Tooling and Super-Source
• * Using the same model classes in Android, GWT and JPA (Part II)

But, none of these told me exactly how I was to accomplish this.

In addition, we had another problem: we needed to be able to pass the URI and UUID classes back and forth between the client javascript and GWT-implemented services on the server, and none of the above blog posts gave a hint as to how to make the Java and Javascript versions of the classes mutually serializable (GWT uses the standard JDK implementation on the server, but the Javascript override classes on the client).

There’s a mechanism for this, as well, but again I couldn’t find good Google documentation on it. I did find How to use a CustomFieldSerializer in GWT, but it deals with entirely custom classes and not classes meant to act as JDK API classes.

We eventually figured this out and I thought I’d put this tutorial together in hopes that others can do the same if necessary.

Tools Needed

• * Maven, 2.2.1 or greater
• * JDK 1.6 or better
• * Eclipse (optional)

These can be downloaded from the websites of the respective projects.

Example Code

This can be downloaded here.

Project Setup

If you don’t have an existing project, you can use the gwt-maven-plugin archetype to create one:

It will prompt you for group id, artifact id, version, and package names; for the example I used “com.example.gwt”, “SuperSource”, “1.0.0-SNAPSHOT”, and “com.example.gwt”.

You will need a working maven pom.xml file that includes the necessary GWT dependencies and the gwt-maven-plugin; the archetype may give you this, although it doesn’t use the latest GWT versions and in my experience produces some errors. The one I used, for example, looks like this:

Create source directories: src/main/java, src/main/resources, and src/main/webapp. You will need to provide the necessary html, css, and web.xml files for your implementation. The example code linked above includes sample sources for these taken directly from the archetype that the gwt-maven-plugin provides.

Create server-side service interface and implementation, and an EntryPoint class. The ones in the linked source are adapted from the “Greeting Service” that comes with the archetype.

Create a JDK-Emulation Module

Create a new module at the same level, in the resources directory, as your existing GWT module. In the example source, I called it “SuperSourceJre.gwt.xml”, and placed it in the src/main/resources/com/example/gwt directory next to the one created by the archetype. It should look like this:

The path in the super-source tag is arbitrary, but must match the the name of a directory directly under the package or directory where you created the new file; obviously you can also set the “rename-to” value to whatever you would like. What GWT does is take the package specified as source-path, and removes it from the front of the path when compiling anything under that directory. So files under “com/example/gwt/jre/java/net” will be compiled as if they belonged to the package “java.net”. This allows you to create classes that get “renamed” to classes in the core JDK. Note that the sub-path then must match the package of the class in the JDK.

Import this new module in your existing module(s). For example, in the existing “SuperSourceTest.gwt.xml” file, I added:

Create the Emulated Classes

In the attached example source code, I emulate both java.net.URI and java.util.UUID, and I also include some fancy JSNI native code to allow me to generate UUID’s on the client side if necessary. Of course, your needs might be different. The key is that only the methods you implement in your emulation classes are available to the client. Although it will appear as though your java code compiles when you are writing client-side code, it will fail GWT compilation.

The classes you need to emulate should be created in a package-dependent path in the resources directory under where you created your new emulation module. For example, I created the classes:

• * src/main/resources/com/example/gwt/jre/java/net/URI.java
• * src/main/resources/com/example/gwt/jre/java/net/URISyntaxException.java
• * src/main/resources/com/example/gwt/jre/java/util/UUID.java

(The exception is created because the URI constructor throws URISyntaxException, so it also must be emulated.) Note that I put these in the src/main/resources directories instead of src/main/java: this is because Eclipse or other IDE’s and compilers will refuse to compile them as java, since they have invalid package specifications, so I put them in as “resources” so they end up in source and classes directories but nothing but GWT attempts to compile them.

Create the source code for these classes. Ideally, you would implement the entire functionality of the original JDK class yourself, but you at least need to emulate a default constructor and the minimum logic necessary for your client. The signatures of the methods you implement should mirror exactly the ones they are replacing in the JDK itself.

Here are the implementations I used:

At this point, GWT will happily compile these classes, but they can only be used on the client side (server-side code will use the original JDK classes). They can’t be passed as service arguments between client and server because GWT will see them as different because their serialized signatures are different.

Implementing Serialization

GWT allows you to specify custom serialization for your classes. The method is pretty straightforward: you need to create a class in the same package as the class you want to serialize named [Class to Serialize]_CustomFieldSerializer. The name and package must be exact, or GWT won’t be able to find the serialization class.

In the serializer class, you must implement two methods:

• * serialize
• * deserialize

You may also implement “instantiate” if default constructor instantiation is not adequate.

For example:

Because we want these serializers available on both the server and client side, they should be placed in src/main/java/… so they will be compiled by both GWT and the java compiler.

This is pretty straightforward, and works fine on the client. But there’s a major problem: the classes we want to emulate are in JDK core packages (java.net, java.util). On the server, the classloader will refuse to load any custom class in core packages (packages beginning with java or javax) as part of the JDK’s core sandboxing. So we can’t place our serializers in the right package.

Apparently this is a problem Google had as well, because their own emulation classes must also often have custom serializers. So they have created a “magic value” package name that their internal API checks for serializers as well as the raw package name. This value is “com.google.gwt.user.client.rpc.core”. The raw package is appended to this, so if GWT were looking for a serializer for “java.net.URI”, they would first check for “java.net.URI_CustomFieldSerializer” and, if none was found, check for “com.google.gwt.user.client.rpc.core.java.net.URI_CustomFieldSerializer” So if we place our serializers in such a package, GWT will find them automatically. Of course, this is internal GWT API to “use at your own risk”, but we haven’t found another way around this problem yet.

So to serialize our own URI and UUID classes, we build custom serializers as (note the src/main/java location and the special package):

• src/main/java/com/google/gwt/user/client/rpc/core/java/net/URI_CustomFieldSerializer.java
• src/main/java/com/google/gwt/user/client/rpc/core/java/util/UUID_CustomFieldSerializer.java

These look like:

The code implementation for both of these is pretty straightforward: serialize the object using toString, and instantiate it from the string.

Utilizing the Classes

Obviously you will have your own specific uses of these classes. To test them, I created a simple DTO bean in the archetype’s shared package:

I then modified the archetype’s GreetingService and related implementation, changing greetServer to look like this:

The implementation was changed similarly, and echoes both echoes back incoming URI and UUID entries and generates some new random ones. This lets me make sure that the equals and hashcode implementations work reasonably well.

Then I modified the EntryPoint to use the new method and display the result. If you’re using gwt-maven-plugin to generate the async interfaces you’ll have to do a maven compile to have those interfaces generated before the code below will compile in Eclipse.

You should then compile this using mvn clean install gwt:run to make sure it works correctly in both hosted and production modes.

Britannica approached us to design a mobile strategy that would take advantage of their content without sacrificing the editorial quality for which they are known. Together, we envisioned a series of small, easy to follow educational apps focused on specific areas of interest to the K-6 market - areas where we could inspire that spark of fascination that makes learning fun. We settled on the iPhone/iPad as an intuitive learning tool that would enable us to make the learning experience deeply engaging.

We launched the series with 3 apps: Dinosaurs, Volcanoes, and Ancient Egypt. The Britannica team put together a promotional video that gives an excellent overview of the product line:

Each app is richly populated with content that has been given detailed editorial review and is tailored to its audience. We’ve included highly interactive games and activities such as jig-saw puzzles, quizzes, memory match games, and a geo-aware map interface that displays learning materials based on proximity to the device’s current location.

The apps have received a number of glowing reviews, including from The Big App Show, hosted by “The Podfather” Adam Curry:

Behind the scenes, the app series is based on a reusable app engine which is designed to significantly reduce the costs associated with publishing new products. Each part of the app is completely modular, and new configurations can be created as needed based on the topics covered in the app.

We took the high road approach to UI design, opting to create new native controls instead of using those built into iOS. While a bit more challenging, this approach allows our UI to pull off a degree of polish that is difficult to accomplish using just the basic controls.

During development, our project came to the attention of Apple, who invited us down to The Apple Campus in Palo Alto. We spent two days there discussing UI design and doing detailed performance testing of our app engine. It was truly informative and really helped us dial in the user experience.

The apps have done quite well in the market, leading Apple to include the UK versions in their Hot Trends in 2010. Apple has also included the apps in their Apple Learning Tour - a traveling roadshow which showcases iPads as learning tools to educators across the country.

We began 2011 with the release of the latest app in the series: Solar Systems, and have quite a few more products in the pipeline. It’s going to be an exciting year. We’re really looking forward to helping usher in the future of education.

Here it is! Our (belated) post about this year’s WWDC adventure. It was a high profile event and Apple did not disappoint.

Aside from the great tech talks, one of the highlights was the effort Apple put into polishing the event. The video below shows a wall of monitors - but this is no ordinary wall of monitors. This demo consists of an array of iPhone app icons dropping into place at a rate of speed that corresponds to their real-time sales. I thought the arrangement by color was a nice touch. I had the opportunity to speak with one of the engineers who worked on this and I was quite impressed with the amount of work that went into it. It was a stunning opener that made me feel really welcome at the event.

Video: The App Store Matrix

The first thing I noticed when I reached Moscone West via the path through the Yerba Buena Gardens was the huge line that started at the entrance, went down the length of the block, and turned the corner.  Fortunately I decided to go inside prior to getting in the line, which proved a good move; to get into the keynote at the front of the line the registration badge was required.  The lines are pretty much the single downside of the WWDC conference; although Apple reserves time spots near the end of the week for repeating sessions that fill up, which is nice.

Badge in hand, I headed outside and down the line to find my place at the end.  It turns out I would have been better off going the opposite way around the block, as the line nearly came all the way back to the entrance around the building.  Fortunately the lines never got nearly so long after the keynote was finished.  But the lesson was still valid: it’s worth getting to anything you really want to see at WWDC as early as possible.

The keynote was impressive. Steve Jobs is quite the showman. He has a way of getting people excited about even the smallest new features. Of course, the announcement of the new iPhone 4 was the most exciting point. Some of the other revelations are quite exciting from a development perspective, but are covered by Apple’s NDA. (If you’re curious, MacLife covered the entire presentation in great detail.)

The tech sessions at WWDC are generally great.  Some are geared for more experienced people than others, so picking and choosing the right sessions can be difficult based on your experience level.  I found that as a more experienced developer it was often a good plan to skip the first session in a multi-session series.  There are also many sessions running in parallel, only some of which repeat, so sometimes one is forced to pick between a few sessions that look interesting.  The Apple engineers at the sessions are generally the folks that are working on the code they’re discussing, so they’re certainly knowledgable. I got a lot out of chatting with them about various issues I’d run across while coding.

While the sessions are helpful, there are two more things that make WWDC a great experience: the labs (which are full of Apple engineers) and the other developers from all over the world.  The labs offer developers a place to go interact with Apple engineers on specific issues with their own code.  I didn’t come prepared to do this, so I spent most of my time in sessions.  However, looking forward to next year’s WWDC I plan to have some example projects for things I want some help with ready to go when I leave for San Francisco.  Lastly, talking to other developers in sessions, labs, and even the lines was generally a great experience.  It’s nice to hear what other people are working on, what problems they’ve run into, and what they’re currently trying to solve. Oh, and the cupcakes were a hit too!

All-in-all WWDC 2010 was a very worth-while experience for me and I hope to attend again in future years.  It’s great to feel like part of such a passionate development community.

As an independent development shop with apps on several platforms, we’ve been tapped by the FTC to provide expert witness testimony on the matter. We’ve spent several weeks giving testimony, helping the FTC understand mobile technology and the mobile advertising space as a whole. It is apparent to us from these discussions that the FTC is not in a good position to understand - let alone regulate - the mobile ad market.

The mobile space is clearly in its infancy and is changing rapidly. At every touchpoint with the FTC, we felt like the market had shifted enough that what we’d said previously was already out of date. Recent game changing events like Apple’s iAd platform - not to mention Alcatel-Lucent’s new ad system that bypasses apps entirely - make it hard to understand why anyone would feel that a Google/AdMob partnership will reduce competition. From our perspective, this acquisition is a positive, reaffirming event for the entire mobile industry.

The deal offers a number of key benefits to the industry:

* It shows that the mobile ad space is an industry to be taken seriously. This trend will draw a host of new advertisers to the space leading to the creation of new kinds of content, powering the development of new mobile hardware, and inspiring the creation of new, innovative ad networks.

* It shows investors that start-ups like AdMob have a viable exit strategy. This will encourage other companies to enter the space to work with the influx of new advertisers.

* It will usher in a wave of innovation in advertising as ads move from simple banners to interactive experiences. Apple has this vision for the iPhone. Google/Admob is well positioned to execute on it for other platforms.

* If this wave of innovation follows past trends, the influx of new advertisers will provide currently unforeseen revenue opportunities for developers across the board.

Our testimony focused on these points, the nature of the industry as it currently exists, and what might happen to the industry under various scenarios. We tried to emphasize our view that mobile advertising is an industry in flux - and as such, we strongly believe regulation now would be premature.

Unfortunately, the industry’s rapid rate of change means that by the time the FTC has its collective head around the industry as it stands today, the industry will have evolved into something very different. This, of course, is a serious problem with many intersections of business and government. ( Finance, anyone? )

With new developments coming to light nearly every day, the future for the mobile ad industry is bright - but it is also uncertain. We urge our colleagues at the FTC to reconsider their position on this issue, approve the acquisition, and move on to more serious issues.

UPDATE: 05/21/2010 - FTC Closes its Investigation of Google AdMob Deal

It sounds like science fiction - but as mobile devices make more and more computing power available on the go, cyberspace and physical space are beginning to intersect in some very interesting ways. Nowhere is this more apparent than in the trend toward Augmented Reality. AR aims to make the entire world digitally interactive - and this opens up some fascinating possibilities.

In its simplest form AR on a mobile device can be thought of as an overlay on the world. For example: You point your mobile phone at a building near where you are standing. An application on the phone can determine your position and the direction you are facing. Using this information the application can look up the address of the building, whether it’s for sale, even if any companies in the building are hiring.

Applications like Layar (shown above) or Wikitude are great if you are able to correlate information with geo-spatial elements. Often times however, this kind of information is not available - or is simply not accurate enough.

Virtual Bookmarks

In situations where the use of real-time location data is not practical, several other technologies come into play. Of particular interest are QR codes. QR codes are a simple method of encoding information in such a way that a mobile device can retrieve it. Think of it as a virtual bookmark in the physical world. Google uses such “bookmarks” extensively in its Favorite Places initiative.

QR codes are quite popular in countries outside of North America. In Japan, QR codes are used on everything from advertisements, to fast food wrappers, to buildings. They have also become something of an art form around the world. A standard QR code is shown below on the left. A stylized Japanese QR code is shown below on the right.

Although the right image has been stylized, both codes are machine readable. The left code will take the user to google.com, while the right code will take the user to Louis Vuitton’s Japanese mobile store.

In the US, QR codes are just starting to gain momentum with a strong showing last week at SXSW. Esquire Magazine recently published an AR focused edition that used a custom QR code. The same trend can be seen in retail stores in Texas.

RFID tags - which can be scanned at a distance - are also staring to move into the mainstream. There are even rumors that Apple might include an RFID reader in a future version of the iPhone. Notably, Apple did just hire wearable computing guru, Richard DeVaul for top-secret research.

Future Trends

As we move towards a more interconnected world, we can expect AR to get better and better. Google is leading the way with Google Goggles, an application for Android-based phones. Google Goggles allows users to search on theoretically any image and retrieve information from the Google search engine. Another Android app - Recognizr - can search social networks based on an image of someone’s face. This, of course, raises serious privacy concerns.

Despite those concerns, AR is a rapidly growing trend and will likely lead to numerous exciting developments as companies continue to explore the intersection of the Internet and the physical world.

With the Internet-crushing hoopla surrounding the release of Apple’s widely anticipated iPad, not much attention has been paid to the exciting additions Apple has made to the iPhone OS to support it. Here we’ll explore some of these changes and discuss what they mean to publishers and application developers alike.

Apple designed iPhone OS 3.2 to support the iPad exclusively - so for now, the iPad’s slick new features are not available on the iPhone or iPod Touch. We’re hopeful that some of these features will slowly migrate over and Apple will release a combined iPhone OS for all devices. Luckily for those of us with large app collections, iPhone apps written for older versions of the iPhone OS should work fine on the iPad.

iPhone OS 3.2 provides applications with several new options for presenting content and receiving input from the user. As expected, Apple has introduced a new set of Human Interface Guidelines to go along with these changes. Below are the features that immediately grabbed our attention.

Popovers

A popover is a floating view that resides above the main application interface. They are designed to eliminate the clutter that might otherwise occur in applications with complex controls. You can see an example below:

The primary benefit of the popover is its unobtrusiveness. It appears only in response to specific user actions and can be dismissed when the user taps out of its bounds. This style of UI design will lead to interfaces that can become as complex as necessary for users that want to dig more deeply - but remain ultra simple for those who don’t. Popovers can also contain split views, discussed below.

Split Views

The split view is an interface element that allows developers to manage side by side content views. Typically, this would consist of a list on the left, with an action area on the right that changes based on the list item selected by the user. By itself this is not particularly innovative - applications have been designed this way for years. But by placing split views into popovers, Apple is treading new ground by enabling developers to create user interfaces that focus on quick access - and this is quite innovative. Think of it like a table of contents that can be accessed from anywhere in the application without changing screens. An example of a split view can be seen below:

As the iPad still does not support Multitasking, the benefits of the split view are confined to individual applications. We’re hopeful that as the hardware behind the iPad becomes more powerful, Apple will enable multitasking across applications. Someday, we’d like to see our favorite Mac application - Quicksilver - inspire a new generation of mobile device interfaces.

Custom Input Views

Until now, user input on iPhone OS based devices has been limited to a simple keyboard - and that could only be used with text fields. iPhone OS 2.2 gave Japanese iPhone users access to Emoji, an enormous set of emoticons popular in Japan. The interface is very similar to a keyboard. It can be seen below:

Apple’s new custom input views give developers the ability to take this sort of user input mechanism to the next level. Not only can new types of keyboards be created - developers don’t need to be confined to the keyboard model at all. We see this leading to innovative speech-to-text and gesture based input interfaces.

Gesture Recognizers

Gesture recognizers allow developers to determine what gesture a user is making on the touch screen. Before iPhone OS 3.2, developers were forced to create their own systems to handle gesture and tap recognition. This led to many apps behaving differently when the user dragged, pinched, or pressed the screen for an extended period. With the release of the iPad, Apple has (finally) wrapped the common gestures into an easy to use library. They’ve also included the most commonly used gestures from across all of Apple’s own products. This feature, along with custom input views, will likely lead to a new generation of iPad gaming apps.

External Display Support

The iPad can be connected to an external display device using a set of proprietary cables. Once connected, the external screen can be used by the iPad to display content. While the iPad itself is limited to a 1024×768 display size, the external display does not appear to be quite so limited. The external display functionality is used by the iPad version of Keynote - but without multitasking, this functionality can’t really be taken very far. Users won’t be able to watch movies on a big screen while they surf the web on the iPad, for example.

Core Text

In order to support iWork on the iPad, Apple has included a high performance text processing library in iPhone OS 3.2. This allows developers to include custom fonts and to create text layouts that go far beyond just a simple text document. In addition, developers can now extend the copy-paste widget itself. The current copy-paste widget is shown below:

By allowing developers to control how this widget behaves, Apple has opened the door to the creation of new kinds of markup. Users could use this control to make the selected text bold - or share it with their friends via Twitter or Facebook. Excitingly, there’s also a spellchecker with user submitted entries.

File and Document Support

Applications that want to share files, can now do so via a simple mechanism - a shared documents folder. When the iPad is plugged into a computer, this shared folder is mounted like a drive on the user’s desktop. An application can also register the types of files it supports, allowing apps to be automatically started when a file of the given type is opened by the user. This will be handy for users that receive many different kinds of email attachments. There are also indications that users may be able to upload files using Mobile Safari.

PDF Generation

Apple has made available native PDF generation capabilities for all applications. Users can now save application data, emails and other text or web content into a PDF file - presumably to be shared or emailed later. This will be a huge feature for applications where the user does a lot of data entry - such as a diet tracking or time tracking app.

Summary

The iPad is clearly the next generation in the iPhone/iPod product line and is aimed squarely at the growing e-reader market. Whether it will be enough to revolutionize the publishing industry the way the iPod revolutionized the music industry remains to be seen. The feature set is compelling, although the lack of Flash support - not to mention the lack of a full OS X operating system - is a significant drawback and may deter widespread consumer adoption. Still, the “Mom factor” might turn out to be the iPad’s greatest strength.

From the developer perspective, it’s refreshing to see Apple continually making available to the community at large the tools and libraries they create for their own apps. Despite the relative lockdown compared with other devices, the iPad promises to usher in a new wave of mobile innovation.

Note for the adventurous: Someone has apparently devised a way to simulate a number of iPad features on the iPhone - and even give it multitasking capabilities. If you try this and it works for you, let us know.

The notion of the iPod as a classroom tool is rapidly gaining traction. Unsurprisingly, Apple encourages educators to make use of their technology - and a number of prominent educators are actively discussing the pros and cons of classroom use. A recent issue of the “ezine” iLearn addressed many of these issues in some detail.

We’ve done our best to address the concerns of educators in our survey system while maintaining scientific rigor. Each device is checked-out to a particular user - who must enter a PIN code each time they begin a survey. User management is provided by a central web application accessible via the Internet. At random intervals, the device prompts the user to answer a series of questions. We built in support for Multiple Choice, True/False and Fill In The Blank question types, all of which can be authored via a simple web interface on the central server.

On the back-end, the server provides a number of administrative, authoring, and data analysis tools. Our goal with these tools was to create an easy to use interface for scientists and administrators while maintaining scientific best practices. To this end, all personal data is encrypted both on the devices and on the server. Data cannot be altered once collected and the reporting engine generates reports using only anonymized response data.

The response from the field has been overwhelmingly positive so far. Kids really like the idea of having an iPod on their desk, teachers like having an easy way to engage with tech-savvy students, and scientists like having a survey system that the kids will actually use.

For our part, we hope this technology will help improve the learning experience for everyone involved.

I was invited as a member of the Promise Neighborhood Research Consortium where I hold Concentric Sky’s seat on the steering board. The PNRC is an NIH funded consortium with a mandate to extend the mission of the HCZ to communities around the US. Concentric Sky is the PNRC’s primary technology partner.

The conference was well attended. There were over 1,400 people present and another 400 people on the waiting list that could not get in. 104 neighborhood organizations were present from around the country and I had the pleasure to speak to a large number of community representatives.

Several Obama Administration officials spoke at the conference, including:

• Arne Duncan, Secretary of Education
• Melody Barnes, President’s Domestic Policy Advisor and Director of the Domestic Policy Council
• Jim Shelton, Assistant Deputy Secretary for Innovation and Improvement, U.S. Dept of Education
• Adolfo Carrion, Jr., Director, White House Office of Urban Affairs
• Ron Sims, Deputy Secretary, U.S. Department of Housing and Urban Development

The presentations focused on several key themes with a central message: focus on outcomes, evaluate approaches, make continuous improvements based on real measurements, and create long lasting partnerships with communities.

The most exciting thing for me was the interest in innovation - a willingness to look beyond what has been tried before and to look forward to evidence-based outcomes. This is very much in line with the PNRC, where I’m leveraging Concentric Sky’s strong understanding of data and social relationships to create new tools for tracking metrics and increasing community involvement.

Since returning from the conference, the PNRC has connected with other Federal agencies, such as Dept. of Education and HUD, to collaborate on their Promise Neighborhoods and Choice Neighborhoods Initiatives.  We aim for our technology tools to be brought to bear on an even wider scale. Where possible, we hope to spur innovation by making some of our tools Open Source. Our collective goal is to build a successful technology model that can be extended to poverty stricken communities around the world.

With the support of the Obama Administration and the AARA, we are well on our way.

Our friends at Google contacted us last week to invite us into the AdSense for Mobile beta program. AdSense is one of those subtle technologies from which Google derives most of its revenue. I’ve always been curious about its inner workings, so I signed us up right away.

After some discussion, we settled on Astronomy Picture of the Day for iPhone as the best candidate for the program. Google is looking for high traffic applications from which it can derive usage metrics before going live with the new system. APOD for iPhone generates millions of screen views from around the world, with the majority coming from North America.

We reviewed the SDK and set to work. The first thing we noticed was how differently Google thinks about content than our current ad partner, AdMob. AdMob provides a simple interface where the developer can choose to enable/disable ads by genre and can filter ads based on keyword or URL. The controls are coarse, but useful. Google, in contrast, prefers to have a target page on the Internet that can be crawled for keywords.

Having the content on the Internet gives Google a key advantage over other ad networks. The domain hosting the target page can easily be correlated with Google’s massive traffic and search databases, allowing Google to use factors such as PageRank to serve up the most relevant ad content.

This is great news for developers - fine-tuned keyword control and the ability to make updates programmatically are must haves in our book.

But what it means to advertisers is not so clear. On the one hand, SEO techniques might have some influence over which ads get displayed for which products. This would be a huge boon to the largest advertisers and development companies. On the other hand, disreputable domains and SEO “black hat” techniques could cause far more damage to a brand than was possible before. This means advertisers must choose development partners even more carefully.

The second thing we noticed was the amount of polish that has gone into the AdSense for Mobile SDK. It was solid, self explanatory, and super simple to integrate. We had it in place and online in less than a day. Comparing this to AdMob and our other partner Pinch Media, we were impressed. Even the AdMob SDK - known for it’s simplicity - took longer to integrate.

After a bit of testing with Google’s beta network, we decided the system was solid and submitted the app to Apple. Apple’s app review process has always been kind to us, so we hope to have the updated app in the iTune store towards the end of the week. We’ll post an update when the app becomes available.

[UPDATE] After a bit of back and forth with Apple, the update finally made it into the App Store today, 11/5.