A lot of times it’s tricky to get real information about a platform. The folks who really understand the internals have a vested interest in seeing the platform succeed in market, and they’re concerned with their relationship with the platform provider. Lots of developer programs are actually run by marketing departments, so they can do a really good job of tempting folks to a platform. And unfortunately there isn’t always someone there to call bullshit and save independent developers from dumping their time into a lost cause. That doesn’t really seem fair at all. Thought it might not seem like it I am actually sorry to harsh on B&N. I’m sure there are some good folks over there who genuinely want to make the world better. But as it turns out I feel way more obligation to the developer community than I do to a retail outlet.

The way this actually started out was my curiosity about what application distribution numbers on the Nook devices would look like. I have visibility into stats from lots of different apps across different platforms, devices, and markets. But I had absolutely no info about the Nook. I do however have a few super simple testing apps sitting around, and some of them are already Android versions. So I thought: “How about I just package up one of the Android ones and release it for the Nook just to get myself some numbers?” Seemed like a simple enough proposition. So I grabbed myself a Nook Color and checked to make sure the stuff I was thinking about releasing wasn’t an exact clone of something already in the market. Nope, it wasn’t.

My first tip off that things weren’t going to he happy shiny in Nookville was the signup process. Just in order to signup as a Nook developer there was a really detailed set of questions to fill out. It was free though, so I just wrote the process off as them being hungry for information about their developers. And I was approved within the timeframe they predicted (I forget how long, important thing is that it wasn’t a surprise). It’s all Android stuff, which I’m pretty comfortable with. So despite some hiccups with their developer mode activation and this completely oddball multibutton process they have for launching sideloaded apps, it only took me an afternoon to get an app together, tested on the actual hardware, packaged up, and ready to go. That’s where it went all sideways.

When I first went in to check on the binary uploader it said I couldn’t upload anything cause my account was pending. I assumed that was just a quirk of creating a new developer account. But as it turns out it was cause I had to enter detailed user account and banking info, even after the details from the initial signup, and even though I only at this point wanted to distribute a free app. So I filled out the details and submitted them. And waited. And waited. And waited. Eventually I started up a support ticket to try to figure out what went wrong (screenshot of an excerpt below). As of right now it’s been a month since I started trying to get my app out, and the support ticket has been open for 24 days. Apparently there’s actually nothing wrong with my info. They just can’t get their systems working.

I’m just assuming at this point that my account is never going to get approved, and that B&N is just going to shut down their Nook experiment well before they get around to clearing up the developer account queue. So just keep this in mind when you’re thinking it sucks having to deal with Apple or Google: at least those systems work.

Since I wasn’t able to actually get an app released I don’t have any hard numbers to share. But there were a bunch of really obvious shortcomings in poking through what was there if you’re planning to build a business. It’s possible that these shortcomings are undone by the power B&N has in marketing your app. They really tout their physical world presence, and their ability to feature apps in-store in addition to on the device. They could be right about that making a difference. They also have an audience that skews female, which could be really interesting if you were able to get an app released. But I suspect the winners on the Nook platform are going to be the ones that have a strong brand already, with “must have” apps getting put in front of a new audience for the first time.

In terms of obvious problems, in giving up the Marketplace you also give up in-app purchase. So the model that almost everyone has adopted to make a profit on the dominant platforms isn’t going to apply if you want to develop for the Nook. It’s paid distribution and thats it. Another glaringly obvious missing feature is remote push notification. You can always hack this in with a background thread polling for updates the way we did pre-Froyo. I haven’t tried that, but I assume it works. It might not really be an issue however. The business reason for drawing users back to an app in terms of revenue model is to expose them to advertising (hopefully not your MAIN reason for drawing them back, but that’s a whole other discussion). However, cause Nook is a closed system that doesn’t allow for promotions for services outside of the Nook marketplace, I assume you’re not going to be able to run any of the existing in-app advertising solutions. Maybe you could run mobile web ads only?

So as far as I can tell this isn’t going to be a winning platform for the average mobile dev. It’s probably a profitable distribution strategy for folks who have a lot of recognition and are looking to get maximum coverage – like Rovio. But most of us are not Rovio.

What about the obvious final question: what about your Nook Color Miker, do you actually like it? Well, now that it’s running Cyanogenmod 7.1 instead of the stock firmware, why yes, I do like it! I’ve been running CM from the SD card, which makes it easy to swap back to booting stock. I’m pretty sure I’m going to be flashing the rom to internal memory though, since I see no reason to boot back to stock any more.

UPDATE: Looks like there are a bunch of issues, and they might even spin off the Nook business unit.

The README has info about how to output bookmarks in a form that the shim will understand. This is just initial hackery, not a real project yet. I just figured I would share it cause, well, taking some JSON and syncing it to the default browser bookmarks just seemed like the kind of thing other people might want to play with. If you turn on install from unknown sources you can download my prebuilt binary if you’re not into the whole Android development thing. Who knows, once I clean it up some I might even upload it to the market. There’s more hackery to be done first. Firefox Sync, I’m looking at you.

It’s too bad bookmarklets don’t work too well in the default Android browser otherwise there would be some much more obvious fun to be had.

So what does that theory have to do with the mobile web? I think it helps summarize one of the primary failure modes for doing mobile web work. There’s a natural tendency to look at the desktop web when thinking about how to address mobile. However, many things that we’re doing on the desktop web just aren’t adjacent to the existing practice on the mobile side. We might make it there eventually, but we can’t make it there now. We assume we know where the mobile web is eventually going TO because we know all the awesome things that grew out of the desktop web, but it’s more important to think about what the mobile web is going THROUGH in order to up the chance of being successful.

For instance it’s pretty natural to assume that because more capable devices are ending up in the hands of a wider audience now would be the time to start working on mobile media properties. However I don’t think the advertising environment is really at the right stage of evolution on the mobile web to make that style of property the same slam dunk as it would be on the desktop web. I think what we really need are a few direct monetization services to kick things off. We need the Amazon and eBay of the mobile web. Those two shifted perceptions on the desktop side, one with direct sales and the other as a sales platform. The media models formed around the commerce that started flowing. I’m starting to think that until the mobile web has something to sell it’s premature to start trying to run media models.

Not that media properties won’t work, I just don’t think they’re what we need to significantly shift development toward the web. And of course, I’m planning to test some of this out cause I might be completely insane. Hat tip to Jay Jamison and Eric Ries for the recent discussions at Founders Labs and Bluerun that have kicked off some interesting ideas.

The state of the mobile web presentation that Dion Almaer and Ben Galbraith from Ajaxian did at the start was a fantastic summary for someone like me. I frequently say “I’m not a web developer” so that no one would confuse me with the folks who live and breathe JS and CSS3. However I’m also not a “native guy” either. I try to use the right tool for the job, so I’m not really in any technology camp at all.

I have a long history of working on the mobile web actually. Sitting in the sessions yesterday I was blown away by how different of an environment we have over quite a short time. In particular during the talk from Alex Russell about browser support and during the state of the mobile web talk it reminded me of a set of discussions we had in June of 2007 about applying the AJAX model to mobile. The points that Dion and Ben made summarized the set of issues way better than I ever have. There are three important components to making a development platform work:

• Platform Distribution
• Platform Capabilities
• Merchandising

The first two points echo the discussion we were having in 2007, with the difference being that now mobile browsers don’t crash if you throw standard desktop JS libs at them. Because we have a nice meaty set of high capability devices in a relatively large number of hands, its finally possible to tune the platform capability vs platform distribution tradeoffs in a way that makes business sense. I think we’re just now edging over a tipping point actually, but that discussion is for another time.

I would actually call their third point “monetization” instead of merchandising, but that’s a nit really. The way they were discussing it, advertising and promotional programs are lumped into merchandising. But this is the area that I think is most in need of help currently. Most folks working on the mobile web are rolling their own when it comes to merchandising. And I don’t really know of many services to point to who are monetizing effectively outside of the app store systems. So if anyone else out there knows of good examples please pass them along. Ben and Dion did make the point that for anyone who has tried to sell software on their own either independently or through other channels, the 30% cut that Apple takes for selling your app on the app store doesn’t seem overbearing. Good point.

Another fantastic point for the day came from Yehuda Katz. He came and presented at the last Mobile 2.0 developer day, but was just settling into the new role. This time around he said something along the lines of (and I’m paraphrasing, so forgive me if I misquote) “people used to have 0 or 1 main computing device they used, now we have 2 or 3″, and addressing that shift is that “mobile strategy” should be about. It should be about delivering the right experience at the right time across different devices. Echoes of the service avatars presentation Mike K did at Mobilize. I think Yehuda really hit the nail on the head in calling out that point as the base of the discussion.

I had already been poking around with JQuery Mobile, Sencha Touch, and SproutCore. Now I’m thinking it’s time to pull together some of the hackery into a project and see if I can make one of them work at scale. Seems like all the ducks are finally starting to line up.

Of course, the way I would like this to work is some kind of digital signature. But I’ve lived through enough failed waves of attempts to bootstrap public key cryptography systems (and have the keysigning party trust signatures to prove it!) that I know better than to try something like that. And all it would really accomplish anyway is exchanging my fools errand of looking for a printer where ever I happen to be with a half hour conversation with someone explaining how yes, a digital signature is a signature and can be accepted for legal documents.

So I decided to figure out a way to be compatible with existing process instead, figure out how to take the existing inputs and emit the existing outputs. But without all that messy physical process in between. I was hoping for something that would record a signature of mine and allow me to just cut and paste it into a document. Instead I found some decent PDF editors for the iPad that allow me to open up an existing doc, sign it with my finger on the touchscreen, and just mail it back. There are actually a few out there that are supposed to be dedicated to this function, but I’ve instead settled on the free Paperpad Lite application. It’s free. So at the end of the day, I’ve found myself a replacement for print/sign/fax that thus far has cost me zero dollars. Double w00t!

The dedicated “signature apps” are supposed to do things like allow you to open up other document formats like Office docs, but in my experimentation so far they generally don’t work. Most of the time the doc comes out garbled. So in those cases I resort to bring up the doc in Pages on my Mac and saving it as a PDF myself. When I’m really in a pinch (like I don’t have my laptop with me and I need to get the doc back right away) I normally just request a PDF version instead. Just watch out for asking for a PDF version from your lawyers, probably less expensive to just wait on those ones :-)

The transformation for me has been pretty extreme. Now as long as I have my iPad with me I can return a signed document right away. That’s more like it! Not perfect mind you, I wish I could do it with just my phone and a click, the way it would be with a proper digital signature. But I’ve eliminated hardware, waste, and a number of digital to analog conversions (which always make me sad). I could probably deal with the “other docs” to PDF problem with a set of filesystems triggers on my Mac, some commandline hackery, and Dropbox. Then even with my Air sitting on my desk at home it could still be working for me.

It’s made me think a decent amount about some replacement workflows enabled by devices. It’s not like using phones/mobile tech to replace paper and scanners is something new. Scanr has been around doing the same for a long time, and with companies like Zosh getting snapped up by document management companies I assume others are looking in the same direction. So if it’s been around for a while as an idea, why start caring about it now? I think it’s a combination of image capture capabilities being at the right level, applications being gregarious enough that I don’t have to worry about by digital documents being locked in a silo once I decide to make the transition, and now the availability of touchscreens.

For me this is a usage that finally turned the corner from interesting hack to useful set of services. I regularly use my Android phone as a scanner now using an app called CamScanner, which automatically crops and contrast corrects the image, and will save it directly off to Dropbox for me. It’s made me wonder about that camera that’s supposed to be in the next version of the iPad. The iPad has made a good paper replacement device thus far, but if it can also pull docs in from paper to ease the transition from existing process we could have a genuine enterprise transformation on our hands. Cool stuff.

I just wanted to point how much catch-up needs to be done. Carriers might think they have some real unique assets. However some of the real core ones are already showing some issues. Take messaging for example. If I have an application on iPhone the notification system built into the iOS platform far and away trumps trying to fall back on something like SMS, both from the app provider and user points of view. And if I’m a website owner who wants to get notifications out to my users? Best way to make that happen is to integrate Facebook so that I can send users notifications through that platform.

So yes, there’s some unique value to be derived from the core services. But take note that the bar has already been raised. We get notifications for free with Facebook and iOS. Receipt of message controls are granular and at the control of the user on those platforms. SMS based services lack much of what we’ve come to expect out of the platforms that we are using. To put together a cross-operator notification/messaging service that’s compelling isn’t going to mean taking the single-carrier model and extending it. Some of these core services need to be rethought before they can be scaled.

• export CFLAGS=’-fno-common -arch i386′
• export LDFLAGS=’-arch i386′
• export CXXFLAGS=’-fno-common -arch i386′
• pecl install xdebug

At first I tried some forms that included both architectures and some optimization flags cause I saw examples of that floating around online (ie. CFLAGS=’-O3 -fno-common -arch i386 -arch x86_64′). But that also was just faulting out on me. Checking the other modules in the Zend binaries they’re straight i386 architecture. I don’t do a lot of remote debugging, but it’s nice to have the option.

Mobile Payments

• The characterization of the panel that Liz lays out is pretty fair, there was definitely a divide between folks who thought that NFC would have an impact and those who thought it was just an expensive stepping stone. Osama from PayPal, summed up the issue as “revamping point of sale vs eliminating it completely”. He stressed that with real world objects being increasingly networked there’s not necessarily a need to have a point of sale. Just indicate you want something right there in the aisle, which flips a bit somewhere indicating a given bit of merchandise is allowed through the doors without setting off an alarm. Smart, and a logical extension of the kind of “Internet of Things” discussions we frequently have.
• Geoff from Mastercard said that they’re working on enabling mobile transactions for unbanked users via Banknet, which sounded awesomely interesting. However, I can’t dig up any info about that effort.
• Geoff also spoke about incentives and coupons getting evaluated and redeemed right along with purchase, so I have to assume that the Mastercard world of mobile transactions sees the consolidation of folks like Groupon into payments instead of leaving them distinct.
• David from Zong was one of the folks who thought that the real value of mobile payments didn’t lie with revamping POS, he said that the value would come from offers, additional CRM hookups, and being able to tie into social networks.

Native Apps vs. Web Apps

• I think the choicest quote from the session was actually Ilja from GetJar: “An app is just an icon. If it’s a web app or a native app makes a difference to the technologists, but consumers don’t care.”
• Jay from Mozilla also made a fantastic point that I’ve been pulling at for a while, that what we normally lump together in the web apps vs. native apps argument around the technologies used to implement applications isn’t really the interesting discussion. The more important issues lie with distribution, monetization, search, and ratings. If Apple allowed web apps in the app store we might divide up the argument differently.
• Michael from Sencha made an interesting point in that he assumed web apps were going to start replacing native apps in the enterprise before the consumer space. He said the desire to avoid device lockin and keep developer productivity high would push enterprises toward the web. Interesting. I always assumed that the need to go cross-platform would push consumer services to the web. But because consumer apps would also give up a bunch of their existing distribution channel in doing so, I can see where he’s coming from. The reasons for not going web currently are distribution and monetization, and in the enterprise you don’t have those concerns. Good point.
• Krishna pointed out that if the browser is the entire OS then the distinction between native and web goes away. I’m sure the folks working on WebOS at Palm would agree.

Service Avatars

• Mike from ThingM laid out some pretty concise points. Anyone familiar with the concept of ubiquitous computing will find a lot of them familiar, but Mike put them into a great overall framework. He was urging folks to stop thinking in terms of individual apps or particular devices in the generic sense – but to think about services and how objects in the physical world can become the interfaces to those services. Don’t think of a camera as a device for taking pictures, but as a peripheral for Flickr.
• The overall argument was deriving from the reduced cost of adding computing. When it’s expensive to add computing to a device you only have a few devices that include computing, those devices need to be generic because they need to fill all the different roles. However, with computing getting less expensive now you can sprinkle it around as necessary, and make each instance of the tech more focused and differentiated. Most people just say “when computing gets cheap enough we might as well add it to everything”, this take of allowing the installations to move from generic to specific is a pretty significant twist on motivations, and a much more compelling framework.

There was actually a ton of additional interesting conversation, but I’m running up against my allotment of allowed blogging time for today. Diving through the tweets for #mobilize and #mobilizeconf should turn up some interesting stuff. Like Om asking why Nokia feels it’s necessary to buy developer love with millions of dollars in contest money instead of just building fantastic product the way Apple has, or the folks from Evri saying that apps effectively boil down to filters and that launching an app should be thought of as a search. Hopefully some of that stuff is out there tweeted, if not I’ll try to dig up some extra time this weekend to get some of it down.

I’m a developer, so the answer to that question has always been no. Although us developers are pretty much “pure” online interaction – we don’t have a lot of the need for offline interaction that lots of other professions do – everyone just assumes that if you’re going to be a developer you’re going to have a computer system of some kind. What if that wasn’t the case however? What if the knowledge of local conditions or business models trumped the other concerns? What are the tools you could use to get the job done if you had a business opportunity and a mobile phone, and that’s it? These are the kinds of questions that have been dragging me out of bed lately.

However, I’m struggling with a big disjoin between what’s possible and whats practical and productive. We’ve gone through the discussions plenty of times before regarding the economics of developing for lower end capability devices (users of those devices segment into different demographic buckets, finding ways to address them is more difficult, etc). So lets just assume that folks using lower capability devices make good users and they’re people you want to address as users.

I talk to a pretty decent set of web developers on a pretty regular basis. Some of them have started to get excited about developing for the mobile web. I hear them say things like they’re happy they don’t have to pick up a whole additional set of markup to make things work on mobile devices, that they’re happy lots of the base functionality is showing up directly in javascript API, and that the layout engines have gotten good enough that they can make pleasing web experiences. Generally I don’t hear too much from the web developers about being able to hit wide swaths of devices with the same set of markup and styles. And I can’t recall any of them saying they’re anxious to supplant the programming models they’ve come to develop with different architecture for web design. Actually, I hear things like “it works on the iPhone, that’s what I have anyway, I don’t care about Android” more often than I’ve heard people discuss how to make things work consistently on both platforms.

Whenever the discussion starts to revolve around hitting multiple handsets, it’s always driven by people already in mobile. It was my impression that the next generation of mobile web technologies was supposed to cater to the existing set of web developers and make mobile an attractive option for them. I’m not seeing that happen however.

So my question is for what group of folks is this going to be the right tool? I’m certainly not a web developer, but I understand the stuff that goes on there. But you don’t even really need to be familiar with the technology, all you have to do is take a look at Twitter on any given day at the discussion going on with web developers. Quite a bit of it revolves around bitching about “cross-platform” issues, which normally means getting the stuff to work on different browsers even when we’re dealing with full desktop layout. Now we’re talking about supporting different device resolutions and orientations all using different browsers (or at least different versions)? I can’t see the web devs I know jumping out of their seats to volunteer for that.

The technique that I see most folks using is segmenting their traffic and swapping things out on the web server. They design for desktop, high capability mobile, and low capability mobile. They detect what device they’re serving to normally based on the user-agent, and then serve up the correct version directly. Both techniques have issues, granted. Lots of issues. It seems like the “new new” of progressive enhancement laid out in the slides would work best when you’ve got:

• Folks working on the implementation who are at the deep end of HTML/JS/CSS
• An environment where the pages need to be static and server side switching isn’t available
• There’s a minimal amount of application logic.. trying to interleave dynamic content updates and event responses with the complexity of adaption seems problematic

Or am I missing the boat here? Is there a way to apply this stuff that significantly lowers the bar for implementers? Or plasters over a bunch of these complexities? Or merges together the different models and techniques? Cause it’s hard enough to convince the web folks I know to even play around with iPhone, we’re just starting to make some inroads there. If I laid something like this in front of them they would probably kick me. So, please, educate me. How do we put things together so that doing web development this way is compelling to someone who isn’t already a mobile devotee?

UPDATES:

PPK is rising to the challenge and trying to lay out how things should be working. Here are his responses:

• State of Mobile Web Development 1/3
• State of Mobile Web Development 2/3
• State of Mobile Web Development 3/3

Daniel Hunt has also followed up, with a different take than PPK, saying that device detection is an essential element of being able to deliver a great mobile web experience.