The presentation started by re-iterating the numbers Facebook released back in October: they have 604M mobile active users with a quarter of those (126M) being mobile-only over the course of a month. They didn’t break out the number of mobile web users but they did re-iterate their previous statement that their mobile website has more users than their Android and iOS apps combined, which doesn’t clear up the recent contradictory speculative numbers posted by Benedict Evans who claims Facebook mweb is smaller than either Android or iOS. Perhaps the answer is that Facebook mweb double-counts users (e.g., iPhone users tapping on Facebook notification email links and getting to mweb) whereas perhaps Ben Evans’ numbers assume zero sum math.

Regardless, I’m confident we can all agree that this is one popular mobile-optimized website.

One Mobile Site

In mobile, we often talk about the challenges of maintaining native apps and mobile websites in parallel. Facebook had magnified this challenge further by maintaining two separate mobile websites: one for feature phones and the other for modern smartphones. One of the presenters, Al Urim, had some visceral pain from this experience: he had to port the ability to “like comments” to both of these stacks.

To solve this problem, Facebook has unified these two mobile websites into one. To simplify the challenges of coping with diverse mobile device capabilities, Facebook uses an XML-based abstract component framework to encapsulate the details of presentation layer rendering. They shared an example of a button, which they suggested would be written as this in their markup:

<m:button>…</m:button>

(Yep, that appears to be XML namespaces; it’s making a comeback!) That markup is then rendered in diverse ways, such as an <input> on some devices, a <button> on others, etc.

They claimed that this mark-up language covers 80% of the functionality of the mobile site, with the other 20% being custom HTML/CSS/JS code for specific devices. They cited taking advantage of CSS3 features and GPU acceleration as common reasons to write this custom code; there was also plenty of grousing about the challenges of supporting lousy Android Gingerbread-era web browsers.

At this point, the presenters emphasized that their number one priority is moving fast; they don’t tolerate architectures that make it difficult to rapidly iterate on new features. They also enthusiastically endorsed the productivity boost of this approach; it really does take away a lot of the pain of supporting a very fragmented mobile web landscape.

Optimization Lessons

The topic next moved to optimization lessons that they’ve learned:

• Consolidate resources into the lowest number of files you can. Put all your images into image file (i.e., sprits), consolidate all JS into one file, etc. This is pretty standard advice as it minimizes the number of disparate connections required to load images (pipelining notwithstanding) and the cost of establishing a connection on mobile is even higher than desktop. (Incidentally, when I inspected m.facebook.com on my desktop Chrome browser, I saw it actually contains a crap-ton of individual JS files and images. But, when I changed the User Agent to masquerade as a low-end mobile device, I saw the consolidation they were talking about. My guess is that they added special features to support modern mobile browsers and whoever did that didn’t take the time to optimize the specialized JS and other assets used for those features.)
• Caching. Turns out mobile browsers don’t have very useful caches. They indicated their site uses App Cache as a work-around and said they were looking at using Local Storage in the future. (I didn’t see either of these getting used much by their site when inspecting with the browser dev tools, for whatever that’s worth.)
• Manual asset reordering. They talked about manually tweaking your HTML file so that the UI elements and data that the user cares most about will render first and the rest of the page elements can load in asynchronously.
• Use CDNs. Akamai, et al. are your friends! This is especially true for Facebook as their one application is used throughout the entire world. There was a lot of discussion about macro- and micro-latencies (i.e., latency establishing connections to local cell towers versus latency crossing the Pacific). Put your static resources as close to your users as possible. Incidentally, my friend and seatmate at the event, Will Lowry, is a former AT&T exec and shared with me that the connection from the cell tower to the backhaul is a big source of latency as it’s usually just a T1.

In summary, some useful tips but nothing you haven’t already heard if you’ve been paying any attention to Steve Souders throughout the years.

Architecture

While their mobile site is mostly server-side rendered, they want to increasingly shift to a more client-centric model. Their current approach uses modern frameworks like Backbone and CommonJS/AMD modules to render the chrome of the mobile website on the client and then they request server-rendered content to display within that chrome. Moving forward, they want to explore building out sections of the site to be entirely client-rendered; that will happen in pieces. Older devices fallback to an entirely server-rendered experience; they use WURFL for device detection.

They talked about their desire to move to an architecture that enables seamless conditional rendering of content on either the client or the server; when I asked them for details, they said this was just in conceptual stages. (At Walmart Labs, we’ve been exploring this concept as well; we’ve been calling it “conditional tier rendering.”)

Front-end Team Structure

Their mobile team has structured their development teams into two groups: a core platform team and “product developers”. The core team maintains the framework mentioned above and delivers capabilities to the product developers, who in turn create the end-user experiences. They said they have a very collaborative relationship between the designers and developers; some designers write code, and some developers have a lot of room to implement from high-level design direction.

They also mentioned that they have a dedicated mobile data team that analyzes their massive pile of metrics and help interpret results from A/B tests.

QA

The team didn’t claim any special cure for the QA pain everyone in mobile experiences. They do a lot of manual testing, but they also have some automation: an internal Node.js-based framework that runs unit tests and web driver tests. Their framework-centric development approach helps a great deal too as that core layer is extremely well-tested. They also mentioned a flip-side to this framework goodness: memory management pain. It’s really easy to run into memory issues with two or more components that each try to load large datasets.

Wrap Up

There was Q&A, but I’ve mixed in the answers I captured with the content above. Incidentally, my friend Will asked when they were going to open up a Facebook Graph Search API, but they didn’t have an answer (“If you are interested in that, please let us know and we’ll pass the feedback up the chain”).

Kudos to Facebook for sharing some of the details of their web app and stack and for hosting the event. We’ll have to do something similar at Walmart Labs soon.

I started the journey fiercely advocating to the industry and to developers that web technologies should be the lingua franca of mobile apps, both during my brief time at Mozilla and later while I was at Palm as part of the webOS team. Alas, the potential of the web was never realized by the mobile web on iOS and Android and simultaneously the native mobile SDKs exploded in sophistication and richness. Consequently, my views on the role of web in mobile have become… more nuanced.

Dion and I have gone into some detail on these views in various presentations; the next one will be hosted at our Walmart Labs facility close to San Francisco on Tuesday December 4th.

I’m also thrilled to join some of the most influential developers of our time for a panel version of this conversation to be held just two days later as part of PayPal’s TechXploration series down in San Jose. Dion and I will moderate a panel including:

• Abe Elias, founder, CTO and former CEO of Sencha (the ExtJS company)
• Andre Charland, former President of Nitobi (the PhoneGap company, sold to Adobe)
• Jeff Haynie, founder and CEO of Appcelerator (he still writes code btw)
• Steve Yankovich, eBay’s VP Mobile
• David Kaneda, Designer in Residence at Benchmark Capital

I can’t wait to hear what comes out of a conversation with such a great mix of experts on both sides of the issues. Abe, Andre, and Jeff know their tech very deeply, Steve is in the middle of all this with web and native in one of the world’s largest web properties, and David will add a fantastic design perspective. Dion and I have both intellectual and pragmatic interest in the topic ourselves with our roles running mobile engineering at the world’s largest retailer.

I hope I’ll be able to discuss the future of mobile with you in person at one of these two events; come join in and tell me what you think–and let’s help each other evolve our views just a little more.

On Friday, we announced that @WalmartLabs sponsored the Pixate project on KickStarter at the $10,000 level. Today I thought it would be fun to spend a few minutes writing about why I’m personally so excited about this project.

What is Pixate?

Disclaimer: I’m not a member of the Pixate team, but I have spoken with them a bit about the project. Take what I say as unofficial but somewhat informed content.

Pixate brings CSS to native apps. What does that mean? Pixate allows for the customizing of attributes of native UI components using a syntax inspired by the web’s CSS standards. It doesn’t aim to apply every CSS attribute in the various CSS specifications to iOS–that wouldn’t make sense. Instead, its goal is to take the “selectors” part of CSS and introduce attributes and values that make sense for styling native components. Where existing DOM-centric attributes make sense in a native context, they’ll be reused, but where new ones are needed, they’ll be christened as necessary.

Doesn’t CSS Suck for Apps?

Many web luminaries have gone on the record for years talking about how bad CSS is as a visual layout tool. I couldn’t agree more. In my personal experience, CSS layout has been remarkably unpleasant. Despite my years of hands-on web development experience, I must constantly refer to documentation, commentaries, debugging tools, and multiple browsers to achieve any sort of complex custom layout–heck, even simple stuff much of the time. I’m not interested in bringing this sort of thing to native, where the tools are generally better.

However, there is tremendous power in this concept of declarative configuration of user interface components. The parts of CSS that have to do with changing element attributes works quite well–and that’s independent of whether or not the particular set of attributes you have to work with are a mess. The selector syntax is easy to learn and extremely powerful. Editing a few lines in a text file can radically change the appearance of multiple interface definitions and can do so in both very general and very precise ways.

Peanut Butter, Meet Jelly

I’ve long had two feet in the desktop/native app and web app worlds. I started my career doing desktop apps, jumped to web when it hit the scene, came back to the desktop with Java Swing and then tried to bring some of that back to the web by founding Ajaxian.com with Dion and evangelizing rich web clients. As part of this cross-pollination, I created a Java Swing framework that worked a bit like Pixate: it loaded in interface definition files created with a UI builder (in my case, the third-party JFormDesigner app) and then applied CSS rules to the components in those definition files. Despite having different properties than DOM elements, it was an easy trick to expose properties of Swing components to CSS.

I returned to this idea a second time when I was in Mozilla Labs working on Thunderhead, an HTML5 Canvas-based UI toolkit experiment: I implemented part of a CSS engine to theme custom canvas-rendered components.

Based on these experiences, I’ve found that the native + CSS approach works really well. After all, it’s really just a fairly simple labor-saving short-cut. Both iOS and Android apps generally store the user interface as declarative metadata that is instantiated into a UI component graph at run-time. Whereas no one I know modifies this metadata manually in the iOS community, editing this metadata by hand is the standard approach for Android developers. CSS gives both sets of developers a tool to centralize the style-based metadata and to bulk apply styling rules across multiple components (and potentially across multiple screens) in one go. That’s a clear win.

Even if the UI is dynamically generated through hand-coding, the CSS approach can still work. It can be applied before the interface is displayed, and again after it is displayed for dynamic effects.

Update: It’s also worth mentioning that both Adobe Flex and the QT project have incorporated CSS-inspired features into their platforms (thanks to the commenters below for pointing this out).

Why It’s Useful

This approach opens up a few interesting use cases:

• Making it easier to customize a single UI for various different contexts; a more flexible form of conventional UI internationalization techniques
• Making it easier for non-developers to customize the design of native screens. The Pixate team has visions of integrating their engine with Photoshop, etc. Hey, if this happens, great. But allow designers to iterate in the CSS file directly is pretty interesting on its own.
• Creating app prototypes
• Dynamically changing user interfaces after app deployment. A huge advantage of the web over native is the ability the change the UI from the server. By serving the Pixate CSS to the app at run-time, the app’s UI can be changed in interesting ways without an app update. Lots of native developers have hand-rolled their own mechanism to do this, but it’s handy to have a general tool like Pixate for the job.

What Pixate Is Not

Pixate is not, and/or in my opinion should not be:

• An attempt at using HTML/CSS to create native user interfaces.
• An attempt to allow you to reuse web-based CSS files for native apps. The set of CSS attributes that a browser supports will be different than the set that Pixate supports. There may be some common attributes, but I don’t anticipate the overlap will be meaningful.
• A way to develop UIs once for both Android and iOS. I don’t want the Pixate team to waste a lot of time figuring out how to map disparate attributes for kinda similar Android/iOS components into the same CSS attributes. Cross-platform leverage is a non-goal. Let the Appcelerator folks figure out how to map Pixate into the same concepts–in fact, it may make sense to have an Appcelerator-specific grammar for Pixate. That would be really cool.
• Some kind of cross-platform development toolkit that blocks developers from developing their native apps the same way they always have. (Sure, developers will have to make some minor accommodations to incorporate Pixate, like including the lib and perhaps occasionally giving UI components a unique identifier.)
• A silver bullet. Sometimes it doesn’t make sense to apply static, declarative CSS to a native UI. That’s okay.

Furthering the State of the Art

I believe that we should support innovative tools creators in our industry. When projects come up that represent interesting attempts to further the state of the art, I try to be one of the first ones in line to buy licenses and support the projects, just like many other folks I know. I’m proud that ‘Labs has been able to sponsor Pixate so generously.

And perhaps it goes without saying, but in case it doesn’t: we’re always looking for great talent and we’re doing some really cool things in on-line and in-store commerce. Drop me a line (beng@walmartlabs…) if you’re interested in joining us.

28 August ’12 Update: Made some minor grammatical corrections and added the Flex / QT mention above.

When it was announced at this year’s Google I/O, the Nexus Q team took pride in the fact that people upon first observation generally had no idea what to make of the device. After playing with it myself for a couple of days, I’m not sure what to make of it either.

It all started well-enough, as I attested to in my recent tweet:

Really impressed by seamless Nexus Q setup and integration with Jelly Bean. Not happy. Life was simpler when iOS was clearly better.

Big bonus points to Q for simplifying the typically tedious wireless network setup process (it uses Bluetooth to send your wireless network config and just requires you to re-enter your password via your Android mobile device). A clear win over Apple TV–and any other consumer device with a remote control I’ve used up to now.

But all that’s mitigated by the physical setup process. Now I have this weird ball–with cables that prominently protrude from its back-side–on top of my entertainment cabinet. The Q team gleefully bragged about their breakaway from boring boxy shapes, but where am I going to put the thing? Sorry, not in the middle of my living room. Whether intended or not, thanks to those cables, it’s going in my entertainment center, like all other devices of its class. Except, unlike the others, it doesn’t fit well, thanks to the awkward aforementioned shape. Hmm.

It turns out avoiding streaming from the phone is a great strategy for streaming from the cloud. So nice to tap the Nexus Q playback button strewn throughout Jelly Bean and have the device quickly start streaming music, YouTube movies, and so forth. Makes iOS seem positively backwards for streaming from the Internet to the iOS device and then from the device to the Apple TV for the same use cases; surely Apple will put in a fix in a subsequent version that identifies when a command to the Apple TV should be sent instead of a media stream.

But the Q’s strategy falls flat on its face since it’s the only strategy employed. I went to stream music from the Pandora Android app to the Q, but of course, that’s not going to work. Oof. And Q doesn’t have any support for my media: my photos, my videos on the phone, etc.? Ugh.

Q plays a standard, circa 2000 WinAmp-esque visualizer when music is playing. My kids find this so incredibly cool. I was a little shocked. I’d sort of forgotten about visualizers. Now, seeing how gleefully they dance and stare at the TV, I wish I had them in the Apple TV.

But streaming video doesn’t seem to work all that well on the Q. I streamed a 45 minute TV show on my Apple TV, using my Samsung receiver’s Vudu app, and using the Nexus Q. Only the Q had any trouble doing it at full HD. And what trouble it had! Eight “loading” pauses–one of which was really long–during the first five minutes of the show. I switched from the Q to just streaming it on the Nexus 7 tablet; after one such pause, it played back without further interruption. It was just the Q that struggled. What a bummer.

The hardware mute switch (i.e., pushing the ball) works great! Love having that. So much better than fishing for a remote to pause the music on the Apple TV.

And then there was my wife’s reaction when I explained to her we couldn’t play back any of our iTunes music on the Q: “What? Oh, that sucks.” It really does suck to have digital media so stove-piped into all of these different proprietary networks. Google is so late to the game here; how many of us are going to start mixing our media across Apple and Google? I don’t think I will–despite Google bribing me with $25 to give them my credit card. I wonder if that’s for bragging rights as much as a bet that I’ll spend >$25 buying media.

So what to make of the Q? Like so many others, I’m left scratching my head. High-production values have gone into this thing (with the exception of the UI in the Q’s Android-based setup app), but it’s not competitive with the Apple TV and it’s triple the price. The software can be upgraded, of course, so it’s hard to get too worked up over the software-specific issues–but then there’s the question of the hardware.

Am I really going to buy a few of these at $300 a pop and distribute them throughout my house? No, I’m going to just have one hooked up to my TV. And if I do that, why include an amp? I’m just going to run it through my receiver. The built-in amp just seems so weird to me. Is it an attempt to justify the big price? Or does Google really think they’re tapping into a big market opportunity?

And then there’s the question of Google TV vs. the Nexus Q. Are they expecting us to buy two TV-connected devices? Or use Google TV for your TV and the Q is just for music throughout the house? At $300 without speakers? Back in iOS-land, I balk at the thought of spending $300 for nice AirPlay speakers. At least with AirPort Express units throughout your house for streaming music everywhere, you get crazy-good Wifi coverage as a bonus and plenty of places to tether USB devices, too. Good luck with this strategy, Google.

I’m just so confused on so many counts.

But one thing is very clear: after initial concerns about where to put the thing, I’ve decided that it’s fun to have an exotic, alien-esque orb glowing under my TV.

Post updated on 7/1 with a note about Pandora streaming and other minor changes intended to clarify various points.

“I think [Apple] are ten years behind Microsoft in terms of security,” Kaspersky told CBR. “For many years I’ve been saying that from a security point of view there is no big difference between Mac and Windows. It’s always been possible to develop Mac malware, but this one was a bit different. For example it was asking questions about being installed on the system and, using vulnerabilities, it was able to get to the user mode without any alarms.”

It is true that OS X benefits enormously from obscurity relative to Windows’ ubiquity by presenting less opportunity to criminals. But what’s driven me to expend the energy to write this blog posting is Kaspersky’s apparent ignorance of Apple’s protracted efforts to redefine the operating system contract in a dramatic way–with security no doubt as one of the foremost motives (and if not, certainly a material by-product).

This game-changer is (as anyone paying attention knows) the introduction of the app sandbox in Snow Leopard and Lion via the Mac App Store, and identified developers aka Gatekeeper, coming in Mountain Lion. If you’re in the consumer software business, I’m not sure how you’d miss these developments, but ignorance of them is even less excusable in the light of the success of iOS, which has pioneered OS X’s sandbox architecture on the world’s most popular smartphone. It’s done a pretty good job, given the complete absence of malware on iOS combined with the world’s largest app ecosystem (by at least one order of magnitude).

It is somewhat valid to point out that Gatekeeper hasn’t shipped yet and the app sandbox on OS X is opt-in and partial, but these are clearly initial, concrete steps towards migrating OS X from Unix openness to a consumer-grade, iOS-ish platform (that will presumably always let the power users opt back out into the wild west).

So yeah, Apple may not have setup a robust mechanism to respond to vulnerabilities in third-party code they modify and distribute (i.e., Java) as fast as we would like, and they may not have something as high-profile as Microsoft’s SDL to market security-consciousness to the world, but given how squeaky clean the platform has been traditionally, this seems rather forgivable (and solvable).

But it should be noted that while Microsoft has simply reacted tactically to insecurity for nearly a decade, causing untold misery and chaos for their users, Apple is taking steps to change the game. It seems that’s how they roll.

A decade behind? Hardly. But then, it’s not to hard to see how self-interest may have colored genuine perspective in this case. After all, the expert in question now has the opportunity to create a new market for their wares in a world where Windows’ dominance is finally on the wane.

UPDATE: Friday, April 27, 8:30 am

In the comments, Dan “dfabulich” writes:

I was right with you up until this point: “Microsoft has simply reacted tactically to insecurity for nearly a decade”

Vista was a huge step forward for platform security. ASLR, NX/DEP, Mandatory Integrity Control, and IE Protected Mode were huge at the time.

The problem is that Vista was late, and so buggy that nobody upgraded. Windows 7 security may be better than OSX Lion, but lots of people are still on Windows XP; their only real upgrade path is to buy a new computer.

I agree with Dan; I shouldn’t have written what I did about Microsoft. Whether Microsoft has reacted appropriately to the massive sea change in internet safety and security that occurred at some point in the 90′s / 2000′s is a separate issue and one I would have been wise to avoid.

But since I did step in it, let me expand on what was going on in my head when I wrote that:

While Microsoft is great at creating security patches and has introduced various technologies to make new versions of Windows more secure, they haven’t been at all effective at incentivizing people to upgrade to these versions of Windows nor at incentivizing software providers to require newer versions of Windows. It would seem that this latter point–putting secure software in users’ hands–is at least as important as introducing the new security features to begin with.

“see7″ writes:

Regarding the Microsoft windows XP situation, this is where apple is now too. OSX 10.5 already ignored albeit still used by quite a few people (e.g. Some in our company) and I don’t think gatekeeper or whatever “magic” apple builds will be backported to even 10.6 or 10.7.

Consider that Windows XP was released in 2001; its Apple peer was OS X 10.0. 10.5 was released in 2007; that makes it contemporary was Windows Vista. Take a look at the relative marketshare between the two; Apple has done a fantastic job of migrating their users forward by any measure, certainly relative to Microsoft.

Is this because Apple users are fanatics under the thrall of a charismatic salesman? Maybe, but there’s a lot more to the Apple upgrade cycle than that. Consider all that Apple does in this regard:

• regularly introduce innovative operating system features that incentivize users to upgrade
• block developers from supporting older operating system releases without going out of their way (by regularly updating their developer tools and gradually removing older OS libraries and docs)
• dropping support for older hardware in OS releases
• aggressively pricing OS releases, making them extremely affordable relative to Microsoft
• rapidly refreshing the hardware line, which takes older hardware out of the system and brings an OS upgrade along for the ride

In my view, Microsoft is not as effective or aggressive as Apple in these points (though obviously the last one doesn’t apply to them directly at all, though given their leverage and influence with OEMs, they cannot be completely exonerated from the last point).

But is it really fair to hold Microsoft accountable for today’s massive Windows XP install base or claim that they aren’t viewing the problem strategically?

That’s a different point and not one I had intended to explore with this post. I’ll just leave it where I should have and say that I don’t think it’s at all accurate to characterize Apple’s position as ten years behind Microsoft.

Thanks Dan for calling that out.

So I came to this book with quite a bit of existing knowledge of Jobs. As many have observed, if you’ve already read a few books on Apple or Jobs, you will heard much of the material in the book. That, coupled with the fact that Isaacson seems to have designed the chapters to stand alone and thus repeated himself a large number of times, led to the general feeling that the book was less about learning about Jobs and more about celebrating his life by reviewing what I and any Jobs fan has heard time and time again.

Still, the new insights (and to be fair, there were many) are worth the price of admission. I also enjoyed the strong editorial voice of Mr. Isaacson, casting Objective-Voice-of-God judgment throughout the book. Maybe it’s because I studied history in college, but I’m comfortable with biographers taking a point of view, especially when they’ve cut their teeth so thoroughly as this one has.

The book ends with an essay by Jobs himself, recounting the lessons of his life. This was a sweet, intimate way to close out the narrative–and I think stands as a testament to the respect Isaacson developed for Jobs.

Ultimately, I think we’re left at the end of the book with ambiguity. Yes, Steve built an amazing company, and certainly if a life is judged by the things one creates and nothing else, Steve’s legacy is tough to beat. But his callous regard for others–including his own family–is heart-breaking. If this is the cost of building attractive widgets, I would hope most would not pay the price. And so it is left to all of us to work out whether we can achieve career greatness at a level of Jobs whilst also investing in and achieving greatness in the areas of life that matter most.

I think that’s how nearly all of us view Steve Jobs: as a stereotype–a template–of career success that is so comically exaggerated that it is not for any of us to attempt to emulate, but rather, for all of us to study and from which to extrapolate small lessons for our own lives, adapted to the contexts of our own situations. His life seems like a fairy tale of the modern age in classic three-act play format, with achievements of such heights as to defy man to best them with imaginary ones, these accompanied by extreme character traits at home alongside the strongest characterizations of great fiction. It’s as if life decide to write the Great American Novel–and succeeded.

For all that, I have enormous affection for Steve as a person. Rest in peace, thanks for the memories, and thanks for the Macs.

(I bought both the audiobook and the hardcover edition of this book. I mostly listened to the book, but I did read some portions. The fact I listened to this may have contributed to my view of the book. I appreciated the introduction from Isaacson, but the narrator–an actor whose name escapes me–would not have been my choice. I also wish they had been able to use Steve’s own recorded voice for the last chapter, but perhaps that was not possible.)

If you had told me six months ago this would be Set Direction’s outcome, I wouldn’t have believed you. Dion goes into some of the details surrounding the deal, including how we came to know the folks over at Walmart and the steps that led us here.

Joining Walmart.com was a no-brainer once we grasped the size and scope of the opportunity. In my role as Vice-President of Mobile Engineering and Dion’s as Chief Mobile Architect, we’ll tackle together the challenge of creating the world’s best mobile retail applications for some of the biggest and most exciting markets in the world, such as the US, China, Brazil, and many others.

How are we going to create top-quality products for a variety of mobile platforms across all these markets? How will we be able to evolve the apps fast enough to out-maneuver our formidable competitors when we have a gaggle of platforms and markets to support? Will Node.js scale to our needs? These are some of the interesting problems we’ll be solving. Sound fun? We think so too.

While Walmart is the world’s largest company and has an army of people already hard at work on managing its extensive software systems, we’ve been given the opportunity to build our own mobile team with a start-up culture within the Global E-commerce group. Think small teams of incredibly talented people being supported by the resources of the world’s largest company.

Want to join us? Drop me a line.

Whoa. It seems to me only a few weeks have passed since I previously posted on my blog back during those first few crazy days at Palm when I jumped onto the moving train; somehow, it also feels like ten years ago. Being a part of the Palm story has been a whirlwind adventure. And now, that adventure takes a new form.

Starting Monday, Dion and I are leaving HP / Palm as full-time employees but staying involved with HP webOS in a consulting capacity. Our post on the Palm Developer Blog goes into more detail on this transition and look to Dion’s blog for his own perspective.

As for me, “bittersweet” perfectly describes my feelings at this juncture. Working alongside the talented team at Palm has been a tremendous opportunity, and the chapter being written now with HP is ripe with extraordinary potential. Leaving the company of this crew is certainly a bitter cup to swallow.

At the same time, I couldn’t be more excited to be starting a new venture with my good friend and colleague of many years, Dion Almaer. We’ll post more on the details of our new company soon, but we plan on spending our time creating quality software and helping others to do the same. A particular focus of ours will be to help folks realize high-quality mobile and desktop app and web experiences using HTML5, JavaScript, and related technologies.

What a fascinating time of change for our industry! The Web has been challenged as the dominant platform for mainstream consumer software experiences–though the contest with apps is far from over. The predicted mobile convergence (with the desktop) is happening now. Independent software developers are now re-empowered to earn a living at their craft in a new and interesting way–they join musicians, directors, writers, and other artists whose products command the attention of large swaths of the general public. The opportunity has always been there, but now the complexity of so much infrastructure required to distribute those experiences has been swept away (though the trade-off has not been without cost).

While at present we see a diverse set of incompatible software platforms competing for the right to distribute the produce of these new and revitalized app artisans and businesses, history tells us that consolidation of these platforms cannot be far in the distance. Reducing the number of app platforms in the marketplace–the “content formats” of the app world–is unquestionably a good thing for developers in the short-term. However, I hope that we can evolve to a place where the content format and device manufacturer are not irrevocably coupled. When you think about it, the status quo is comparable to a sort of bizarro world where, say, Sony MiniDiscs achieved unparalleled ubiquity but Sony never licensed the format to other device manufacturers.

Of course, this “bizarro world” I described is how the world played out in the last set of consumer software platform wars, but perhaps this time around a large set of developers will choose portable content formats and ensure that competition and innovation thrive for the next exciting decades to come. And hopefully, Dion and I can play a role in shaping that outcome.

More soon.

(* The analogies above aren’t perfect, of course; cut me some slack. I’d love to write another post that goes into detail on the similarities and differences between traditional content media and interactive content, etc.)

While a blog post isn’t the right avenue to talk about all of the issues that Jamie brought up, we’re following-up with him directly and will bring it to a conclusion. We obviously goofed in how we communicated with Jamie, and Dion and I take some of the blame here as our staff had been waiting for us to come on-board to get to some of these items.

We do want to take this opportunity to clarify a few things and share with you a bit about where we at Palm are with our developer program.

Our App Catalog is very much in beta right now, precisely because we want to take time to get it right prior to a full consumer launch. We have been collecting a bunch of feedback from developers and it is helping us prioritize and structure the program. In the brief three months since the launch of the Palm Pre, we have learned a great deal from the community!

We’ve seen some folks assert that Jamie’s case indicates a general pattern at Palm that we don’t really care about developers and aren’t operating in a developer-friendly manner. While we undoubtedly have some work to do here, we hope that people do notice how we treat the “homebrew” community (e.g. PreCentral) and how our current SDK agreement calls out the inspectability and reusability of our own Palm applications. (By the way, several applications from the homebrew community have already made it into our App Catalog.)

While we have yet to finalize and announce our developer program, we hope these points demonstrate our general attitude of embracing developers and empowering them. We’re trying to strike the right balance between locking down our device and making it a free-for-all. Like all great things, this will be an iterative process and we are eager and open to your participation and input to make it better for everyone.

We are sorry that Jamie feels the way he does, but we’ll fix what’s broken and are going to deliver a fantastic opportunity to developers as they in turn help create a fantastic experience to users.

We have a lot more to say on this topic, so watch this space. Dion and I are part of the developer community; we’re listening to what y’all say and we’ll speak up and participate in discussions.

And hey, look for an announcement soon that goes into more details on our developer program.