techno.blog("Dion")

I love the Web, but a couple of things have gotten me thinking.

#1: Netflix on PlayStation 3 via HTML5

I got to meet some of the awesome engineers behind the HTML5-fication of Netflix experiences, specifically folks in the TV group. They showed us various UI experiments and it was beautiful to see. The UI is slick and modern, and every effect is using CSS transition goodness, nicely hardware accelerated thanks to the PS3’s GPU.

At first it may seem a bit crazy that the team took Qt/WebKit with them as the rendering platform, but when you think about the huge number of devices that Netflix needs to support, it makes “wanting an iPhone and Android app” seem like laughable fragmentation.

#2: Trusting the implementations to catch up?

We have amazing browsers in modern devices. But as we push the Web forward, we are still facing buggy implementations and varying support. Although WebKit lives within Mobile Safari, that doesn’t mean that Mobile Safari has open sourced everything to WebKit. The touch support isn’t there. We can’t all use the same scrolling effects and the like. That has to be built up by everyone.

Ideally, with position:fixed (now in Android), you could use that and even flexbox to use the core scrolling of the browser itself so you don’t have to resort in the mimicry that frameworks have had to do until now.

Even the magical escape chute to the GPU via CSS3D isn’t a silver bullet.

Matthew Farag has a lovely portfolio site that uses the power of this modern goodness (using Scripty2 for auto hardware acceleration!). Works great on a desktop WebKit, but how about the iPad? It does pretty well, but you start to see some of the buggy issues where the GPU seems to run out of memory and you get weird artifacts.

So, when you put these two together, you realize that it could be nice to carry a great consistent Web runtime with you to allow you to get great experiences, especially while we are transitioning and getting everything flushed out. It would also enable us not to be beholden to the likes of Android and Apple to make sure that their Web runtimes are fantastic.

I may want Chrome Frame for devices more than I care about it on the desktop as it turns out. Hmm. Alex? ;)

When we talk about the mobile Web being a good candidate to be a unifying platform for mobile and beyond, we often get nay-sayers telling us that there is no chance of this happening.

Their claims often chanted include:

• Cross platform never works (case in point: Swing)
• You can’t create a great experience without going native (and Apple raised the bar on the experience!)

There is some validity to some of this, but I also wanted to discuss the other side too.

Cross Platform Did Work

Swing gets bashed because a) it didn’t take off, and b) people always saw Swing apps as ugly and great examples of the uncanny valley. That team worked tirelessly for many years to try to get the look and feels to be as exacting to their hosts as possible. A pixel off here and there…. and it felt wrong.

It turns out that this probably wasn’t the right approach, and either a) Use SWT to use the real OS components or b) create a great looking l&f that is different to any one host, but natural and fantastic to use. Ben, Jasper Potts, and others fought for such a look and feel in Nimbus but a lot of time had gone by.

We have all seen many platforms on top of hosts that don’t feel right and don’t look good. That doesn’t mean that cross platform can’t work. Flash is an example that is very much cross platform and that community very much went the “every app will have its own UI”…. probably TOO far in the other direction ;)

In fact, the Web itself is a fantastic cross platform success. We have argued that if it wasn’t for the massive Web revolution, would non-Microsoft vendors (read: Mac OS X) be in the situation there are now? Or would they have followed in the wake of Atari, Amiga and BeOS? When the Web happened, suddenly the interesting actions that people wanted to do on a computer were dominated by the global scale of the Web (Google, Amazon, Yahoo!, eBay, etc). The Microsoft Office lock-in was gone (aside: it also DID help a lot that Microsoft gave Apple money, got Office over there, and solutions like VMWare enabled those few Windows apps that you still wanted to come with you).

The Web was a great cross platform success, even though its rich capabilities in the areas of graphics were laughable…. as I mentioned in an earlier post:

When you look back at many of the earlier designs of the top website brands, they are comical by todays standards. However, at this same time, technology such as WPF was being touted on the desktop. Why would people visit Web sites when they could experience amazing native Windows and Macintosh experiences?

So, I don’t think you can discount the Web on the merits of “cross platform can’t win” as it already did win once, and at a time when the capability gap was much wider than we now have with HTML5.

Compare this native app to their Web site!

I teased about the Delta mobile Web application before. If you compare their iPhone application to what you get if you go through a mobile browser, the difference is huge.

But, is the reason they are so different due to capability? I think not. I think the reason is much more about structure, legacy, politics, and history reasons.

I remember seeing an early viewing of an Adobe AIR eBay client. The thing was so rich, so much better than the awful eBay site in almost every way. It made you want to cry looking at the website afterwards. Why or why would eBay have this fantastic client and not spend time on the website where all their customers were! It wasn’t that they were baffoons, it was because they had no legacy in this new world!

The designers had free rein with a blank sheet of paper. They had core concepts and some design language, but total creative freedom. Compare that to the website. If they changed the color one hex value users would go nuts! Every time Facebook changes their site there is a massive campaign to change it back for the first 2 weeks.

They also didn’t have to run the gauntlet of the massive codebase that had been built over years to make any of these changes. And the QA. Ugh.

In fact, an entirely new team could be formed to do this work.

This is exactly what I am seeing in mobile. In many companies, if there is a mobile group, they are just that…. a very separate group. In a non-mobile-thinking company they are like the old “Mac” group in a Windows heavy shop that hangs in the corner and is very different.

Other companies are still getting into the world of mobile and realizing that usage patterns are going in that direction. They are bringing in consultants to help out. They are forming new crack teams to take on the challenge. They are realizing that they need to re-think the entire experience, and hopefully realizing that they need to create software as-a-whole in a very different manner.

The bar on the quality of experiences on some of the mobile platforms is very high indeed (and very low on others!) which has the (great) effect of pushing the bar forward.

Will this leave the Web versions behind? Maybe in the short term. Kinda like how the old Twitter website was simple compared to Tweetie and other clients, but #newtwitter is much richer and borrows some of the concepts where they make sense.

I am definitely seeing people swing back to their web experiences. As multiple platforms foster in touch and cross device, they are starting to feel the increasing tax of building totally different applications across the fragmentation, and then trying to keep them in sync once the 1.0 is complete. Outsourcing the 1.0 is one thing, but the syncing part is hard.

Back to Delta. You will notice that the screenshots on the web side get increasingly poor as you go deeper into the experience. Contrast that with the iPhone version above that is always at a high quality. It is time for them to go back to the web side and sync up.

In fact, just before a recent talk, we coded up some of the simple transitions and feel just so show how easy it is to get some of this stuff working via the mobile Web. You can see the simple example here.

In our Palm Developer Day keynote we shared some of the high level pieces on how to put this all together, the major piece being that you have to really re-think the way that you architect your applications (think: Gmail not server generated HTML, Backbone.js, and more).

Here are some of the slides:

aside: Dave Balmer goes into some depth in his Rockstar apps with HTML5 talks.

Of course, it isn’t all hunky dory. There are still edge cases on getting things performing just right using the Web on the various devices. You have to think “cross platform” again. It may have been nice to ignore that and hack on a native application for awhile. But, would you rather be porting between proprietary SDKs and languages all day long? Or re-use as much of your code as possible.

And, if for some valid reason you really DO need a bit of native for something, you can break out of jail and do just that. The escape chute is waiting for you.

We have a long way to go on giving developers better access to native capabilities and tools to make building the next generation of apps more of a breeze, but it is doable right now (another aside: webOS kinda proves that right now as the native apps ARE Web apps!)

I will finish with the interesting take from Venture Beat the other day on how
the iPhone app is the Flash homepage of 2010. They say:

In the late 1990s, it was common for companies to spend $50,000 to $150,000 for a Flash homepage that looked like a beautiful brochure. However, they soon learned that Flash was cumbersome, slow to load, expensive to build, and hard to update, and moved on to HTML. Now only specialized, high-end sites are Flash only.
The exact same thing has replayed itself on the iPhone. Companies have paid $50,000, $100,000, and more for an iPhone app. Now they have to keep the iPhone app in sync with their regular web site, and have to add additional native apps, each at a high price point, due to the hypergrowth of Android and newly viable platforms like Windows Phone 7

Today was a big day for us, moving into the new pad on University Avenue, Palo Alto. Not a bad place to be! Major kudos to Spencer Tall of Allegis Capital who are letting us hang with them as we incubate our ideas. It is majorly appreciated, and exciting.

Once we finally settled into our offices (after a trip to the Apple Store, just a block away!) we sat down to look at the view, and we giggled to see that it was this:

We are staring at the front door of Sencha! It feels like we are on a stakeout to see when Abe comes and goes. We took this shot and sent it to Abe just to let him know that we are “in position” ;)

We said “hi” to our Sencha neighbours and man did they seem in good spirits. The very recent SenchaCon was a huge success. It was there that they announced their 1.0 of Sencha Touch, and that it was to be free. This is great news for the mobile Web community at large. The segment is buzzing with jQuery Mobile, Enyo, Sencha Touch, and more.

Congrats to all, and Abe….. looking forward to being your neighbour mate.

The Palm Developer Day in New York City was a ton of fun last weekend. Greg and the events team did a bang up job, and it was a pleasure to continue to hang out with the webOS community. Seeing old friends was great, and finally being able to put a face to a name or a nick was great too (highlighted by meeting Rod Whitby of webOS internals, all the way from down under!) This community sure is passionate.

A strong thread throughout the show was the importance of cross platform solutions for developers. There was great content such as a cross platform framework landscape review, and PhoneGap, and a panel including the likes of Charles Jolly of Strobe/SproutCore.

The icing on the cake though was the coming out party for Enyo (greek goddess of War), a next-generation touch UI framework from HP.

It is important to understand where Enyo came from. A chap called Matt McNulty was one of the reasons why Ben and I joined Palm way-back-when. We had been working with him on a webOS-bespin hybrid which later became the fantastic Ares Web based IDE. The layout system is still best in breed, and being able to deploy from the Web to your phone is just awesome.

Those in the Ajax community, especially Dojo old-timers wouldn’t have been surprised to see this level of polish and innovation. Scott and Steve created the grid that was donated to Dojo.

The team behind Ares were not using the Mojo framework, but rather another one (Opus) that would morph into what we see with Enyo today. Going between an Ares application and a Mojo one has always had friction, but that will all be changed with The Unification happens. You will be able to go between the UI builder tool (Ares) and hand coding, no sweet.

There are a bunch of modern touch UI frameworks these days: Sencha Touch, Sproutcore Touch, iAd JS (really!), jQuery Mobile, and more. I am excited about Enyo being added to this mix. Here is why:

Performance

This has been the number one goal, and I have seen the massive difference that it makes on webOS. Enyo based apps start incredibly quickly and stay smooth. This is an area that webOS needed to improve (performance) and Enyo makes huge strides (especially when you also add the work that the entire platform and apps teams have done). Fortunately a lot of the top frameworks are starting to do a really good job here. They are using similar tricks around: keeping a virtual tree and only going across the DOM boundary as little as possible, trying hard to keep animations and rendering on the GPU and without triggering re-renders whenever possible via CSS3 tricks.

Developer productivity

Ares developers have told us time and again how fun it is to write apps. It is very easy to get going, and this goes beyond the great tools. The Enyo framework itself has some fantastic developer ergonomics, especially around layout and the event design, which also helps make sure that you don’t leak memory (obviously a huge thing on mobile).

Cross device

Another major goal with Enyo is the fact that it has to deal with the number of devices coming out of HP running webOS in the future. This is huge, because a massive pain points for developers right now, and in the coming years even more so, will be the need to handle many resolutions, dimensions, and capabilities for the touch world. By solving this problem in a unique way, Enyo makes this a strength. Scott Miles (or as I call him, The Architect) showed off an email client that is in “phone” mode (list of emails) when in a narrow window, but as soon as it got big enough (say, a tablet size resolution) the layout changed in real-time to offer a different view. Being able to share views, and have magic components that can even do a lot of the work for you, is fantastic when you think of building applications that span mobile and tablet (and others). Beyond this though, what about Web apps? I have often said that I wish that I could run a Twitter app in an IM-like configuration (long thin view) looking like echofon/Tweetie/etc, but as soon as I maximise it or stretch it out, it uses that real-estate to become more like Twitter for iPad or TweetDeck. Enyo makes this very possible indeed.

ASIDE: I had a bit of fun with doing this manually with the “hello world” style site setdirection.com which changes between browser, mobile (including landscape and portrait).

Cross platform

Enyo is too good to be stuck on any one platform. I think that the folks behind webOS know this. Having a set of tools and framework like this available for the Web as a whole is going to add to the growing list of quality frameworks that are available for true touch applications (not just DOM sprinkling libraries).

Having this discipline is also added by the fact that you can then spend most of your time developing in a browser rather than an emulator, and thus use all of the browser debugging tools that are available.

Conclusion

Firstly, congrats to Matt, Scott, Steve, and the entire team for showing us a glimpse of Enyo. I can’t wait to have developers play with it. Go Web.

It is great to see not only PreCentral grok its importance, but also Engadget and others.

My last post discussed how special URLs are. They are loosely coupled strings of candyfloss and should be loved and respected.

Thus, a trend that I always makes me squirm is “sharecropping” (as Tantek would say) and not giving people your real address. You have all seen it:

• A TV ad that ends showing facebook.com/toyota instead of toyota.com
• A newpaper ad that just asks you to “follow” them with their Twitter URL
• “Check in” on Foursquare
• I was in a European airport that had billboards showing how to get info via their application that is “Available in the App Store”
• Remember AOL keywords?

On many of these services you are only renting space. You are sending traffic to the host of the system and helping them with their Google juice. I understand how you think that the hip kids just want to go to your Facebook page, but why not send them to your own URL that can deliver an experience that makes sense for them?

You get a lot of benefit:

• You are building your own SEO juice
• You inviting the user to your own house, and can thus own the relationship
• As a good host, you can choose the experience that you want to offer. For example, you can deliver an experience that makes sense for the given device AND what you have to offer.

This isn’t to say that you should tell the user where you are on the various services where they hang out.

I prototyped App Discover as a way to do the marriage between the users devices and what you have to offer. Hopefully sites will grow intelligence to give you an easy way to not keep telling you “download the app!” when you visit the site through your mobile device. The Delta mobile site throughs the above in your face, and since they have no way to query the system to check “hey, if the user has already installed the app, don’t bug him”, it bugs you. I always find it strange to open up the App Store itself and see it tell me about apps that I have already installed. Really? A lot of work to be done on discovery.

I think it is time to take some ownership of your URL, and treat it like a garden. Keep working on it.

A lot of time and effort has been spent by people discussing how the native platforms are superior to the Web recently. What is interesting to me is that many of these have always been the case.

“Wow, iOS applications are so much richer graphically, and you have much better access to the native environment”

Ben and I often talk about how the Web has changed over the years, and how the era of Ajax brought more focus to design in the Open Web platform (because you could [albeit via hackery] do more on the client without having to ask the server for every darn thing).

We compare how sites have changed, for example:

A core Web company such as Yahoo!

A design heavy company such as Disney:

And also Apple:

And, finally, we tease Google a little:

When you look back at many of the earlier designs of the top website brands, they are comical by todays standards. However, at this same time, technology such as WPF was being touted on the desktop. Why would people visit Web sites when they could experience amazing native Windows and Macintosh experiences?

The Web is always behind (in some ways), almost by definition due to the fact that it is based on Open standards. When you look at what you can do with the Web today, it actually compares a lot more favorably to the native desktop experiences that it did back then!

It turns out that the Web has some nice features and function. This isn’t about a ra-ra Web moment, but native folk should also use this as a way to make their platforms and applications better.

URLs are amazing

The Web offers a shared platform. The glue that binds the Web together is hyperlinks. My Mum can put up a website and join the shared fabric instantly. Her work can be found on Google, shared on Facebook, and quickly forgotten about on Twitter. All without having to talk to ANYONE. No deals. No vendors. Silent. That is pretty amazing.

Her work can join the shared stack as folks browse around the constantly changing event based Web. Not only can it be linked too, it can be embedded in various ways. The collective can all work on top of each others work in simple and interesting ways.

This is very different to the app silos of iOS for example. webOS and Android are better in different ways, and have some hooks that allow you to mimic the behaviour. In webOS you can cross scene push actions between applications and Android has a rich system of intents. Once you use these systems you wish you had them on the iOS…. e.g. being in an email, tapping on a link to go into a browser windows, and then going back to the email in a humane manner.

The mobile Web can really shine here if we can get that experience up to snuff. This clicked for me after talking to Charles Jolley sometime about a SproutCore application and differences between serving the mobile app on http vs. via PhoneGap/native app method.

Let’s say I have two native experiences installed on my iPad. Twitter for iPad, and the New York Times app. I am reading my Twitter feed and tap on a link to a nytimes URL. Ideally I may enjoy having the native experience take over, but it doesn’t as we are in silos. It would be nice if the native system would allow me to register a URL handler so the New York Times app could say “hey, if you see a nytimes URL, hand it to me and I can take care of it” (of course there are issues of preferences and choosing which app to launch etc).

Now imagine that the Twitter and New York Times solutions were done using Web technology, and could run via http and natively. Now, when you share a nytimes URL with me, I get the FULL experience passed over to me.

The Hackable Web

The fact that the Web is so hackable is a true gift too. I talked about the fact that you can embed and compose cleanly. “Mashups” are really powerful. The Facebook platform is a mashup. I feel very empowered on the Web as I know that I can change things…. and small things can frustrate me. I want to see the name of someone on Twitter instead of their handle (”Frank Davis” means more to me than “fatgopher” for all but friends that I know well or who tweet so much that I learn quickly). Echofon drives me nuts in that I can’t change this setting as I can in Tweetie (although Tweetie is so behind that I suffer through on Echofon :/).

If this was a Web application I could greasemonkey / extension my way out. There is always a power tool in reach. The core developer doesn’t have to build out a “plugin API” for me, but if they care about not breaking me they CAN expose a nice API as the Gmail team did back in the day. You can trick out twitter.com in so many ways thanks to the userscripts that are out there, and whatever you want to write yourself.

Now, this is far from mainstream. Sure, the good stuff can be wrapped up as a browser extension (and packaged together a la Better Gmail), but I still feel like we have a ways to go to make it easier for people to trick out their experiences. If my Mum goes to Twitter she will never realise there are hundred of ways to change that experience.

The Web has reach. You own your nodes (and can change what runs there at your convenience). It is still simple to get hacking on compared to most platforms (even if advanced things are hard) and remember: Distribution, distribution, distribution.

As we all push the Web forward, I look to see how we close the gap even more so with the proprietary platforms, and how we continue to surpass them in ways too.

You may think that this post is going to rub in the bad press that Microsoft has gotten around their Silverlight positioning coming out of PDC, but it isn’t.

It isn’t really about Microsoft at all. This moment did just spark with me though. Ben and I have been thinking a lot about application ecosystems thanks to our time at Palm. We did research and study, and part of that went back to history. One meta (and fairly obvious) point was remembering how lucky we are to have the Web. I have talked about the history of mainframes, microcomputers, pcs, consoles, you name it….. proprietary operating systems and SDKs ruled. Microsoft took the 90s with a massive lock-in due to software. The Internet changed the entire game and managed to break those chains. Office wasn’t the most important software anymore. Everyone wanted to get onto Google and Yahoo! and Amazon and Facebook and …. and that happened to be on the Web in a virtual machine of sorts (which in my opinion helped Mac OS massively).

For the first time, the dominant platform wasn’t owned by a single vendor. It was almost lost for awhile with IE, but massive thanks to Moz/Firefox and others it wasn’t. It isn’t like a bit that flipped then can’t be unflipped however (and Scott talks about how the Open Web could be closing).

Back to Silverlight. When it was launched there was a massive push from Microsoft to get developers (which they are good at). WPF everywhere. The future was rich interfaces and the Open Web wasn’t up to the challenge so you have to use a plugin. You remember the massive deals to get distribution (Olympics etc). They push hard! As a Microsoft developer you could feel well aligned with what is going on. What about the Flash developers they tried to lure over…. and Web developers too? This is where the problem comes in. With every alignment with a single source, there is probably going to be a misalignment at some later date. Companies have to change strategy as the world changes. Silverlight was “cross platform” (a big deal for Microsoft to do at the time) but this meant “Windows and Mac (oh and we care about Linux via Mono honest!)”

At that time, that is what cross platform meant. Amazingly, a few years later and you laugh at that as when we talk cross platform we also include: iOS, Android, webOS, Blackberry, and you can keep on going. The world changed in a massive way. Silverlight is nowhere to be seen on more of these platforms, and thus it doesn’t make sense as the thrust of Microsoft’s strategy. I am glad I didn’t bet on Silverlight as a developer. I would be sitting at PDC feeling misaligned and hoping that either: a) WinPhone 7 does amazingly well, or b) happy to jump to another platform. Silverlight isn’t “dead”. It will go on. But it isn’t the same play.

Some are talking about how it is now just the WinPhone SDK. I don’t think this is really the case. I have heard that the browser on WinPhone 7 is a frankenstein fork of IE7 with some IE8 and maybe 9 patches and code put back in. Shipping a version 1 (or 7) of WinPhone was a massive undertaking and at some point you gotta ship. I would bet money that the team isn’t standing still and we will see the browser get better fast and join the world of IE9 with all of the goodness that will come of that. I hope that at this point they will be able to push the browser runtime as a first class citizen on the WinPhone platform. I got to play with the phone a little. The core apps were snappy but third party ones were …. not so much. I was told that the core apps are actually written in C++. Hmm. (To compare, the webOS core apps are written using HTML/JS/CSS, same as the SDK, you can even take a look at the code on the device! :)

Aside 1 There is a lot to learn from Silverlight. I would love to be able to have <script type="text/ruby"> that worked across the Open Web in a performant way. Being able to use languages that you prefer is great. Not everyone wants to write in JavaScript (even though some of them probably don’t get the good parts ;). Some fantastic video support. A lot more. We need to learn what we can and include what makes sense in a webby way. This way we can help the IE team make the strategy work for Microsoft.

I have a love hate relationship with autocorrect. When you type gibberish and it automatically converts to what you really meant you let out an “ahhhh”, but when you type something correctly and the system gets in your face and switches it over to something else you get mad. I find that I often know when this is going to happen. When “almaer” turns to “Almaer” in a case sensitive field I growl loadly.

Google acquired BlindType (video above), which is one example of dealing with this particular issue, and it is great to see technology in this space (e.g. Swype). I am sure we will see a lot of new technology come around to make life easier for those who want to quickly navigate around, or get a bunch of content into the device. Have you ever wanted to reply to an email while mobile with something of substance and be frustrated, knowing that you will have to hammer out the thing on a small keyboard? I have. Using voice input has been very mixed, to a point where I don’t try it.

I got thinking about how I would love to be able to use voice actions whilst typing. After all, we do that in other ways. Look at an Italian using his hands as he talks, or a radio DJ make changes as he raps. My particular urge was to say “set spellcheck off” as I typed something onto the device that I knew it would want to correct. Once I did this once, it kept coming to mind as I did other things. When in the browser opening new tabs, sometimes I want to open them up in the background, but other times I want to open them in a new tab but jump right to it. The browser could give me a slightly different key combo for that, or I could say something like “jump” as I complete the action in question.

Once you know that you don’t have something that you want, it is frustrating. I showed someone how they could hold down the home button on iOS and speak to the system “call Dion Almaer mobile” worked like a charm. They then tried “open Facebook”, but to no avail. It feels like it is only time for systems to open up voice as a first class citizen here. Any third party application should be able to add their own voice commands into the substrate.

Once again I feel like an ape at my computer. I can poke and ug (point and click), and I am starting to be able to do more touch, but let me speak and use other senses! SmelloKit where are you?!

When we joined Palm, we were excited to join the intersection of mobile and Web. It has been fascinating to see how that seam has grown over a very short period of time. The device landscape has exploded and developers have amazing new hardware to target. webOS embodies the spirit of joining Web and mobile and we have enjoyed growing the developer community but with its new home at HP we thought it was time for us to move on and allow their resources to take things to the next level. As Ben mentions on his own reflection, it is bittersweet to leave, and I really want to thank Palm, HP, and the webOS community that have embraced us and the platform. I also want to give a massive thanks to: a) the amazing engineers who developed webOS, b) the developer relations team that care so much about our developers, and of course c) the developers who created great experiences on webOS. I wish everyone the best, and as we mention on our post on the Palm Developer Blog, we look forward to continued involvement with the community in our new role as consultants.

What’s next? I have enjoyed time at large companies and small, and there are pros and cons to both environments, but it is time for me to swing back to “small”. I wrote about how the culture of joining companies after an interview is akin to marriage after the first date, so I am not looking to dance down the aisle just yet, no matter how pretty the bride is ;).

Instead, I am incredibly excited to start a new venture with my long time co-hort, and best mate, Ben Galbraith. We have learned a lot about the trials and tribulations of being a developer for the mobile Web, and have some ideas on how we can help people create compelling experiences using HTML5 and related technologies in a highly productive manner. We care passionately about developer community, and are interested in helping companies understand and do the right thing by developers. Finally, we are makers, and have some ideas of great products to build. We look forward, as is our DNA, to share the journey and experience as we strive to build great software.

Industry cross roads

Scott Rosenberg posted on the Web parenthesis and questions whether the Open Web is closing. We are so lucky to be in a position where a massive global platform is Open. If you look at our history with mainframes, PCs, and gaming consoles, they have all be closed proprietary systems. As developers we have been beholden to the vendors. When we are both aligned, things can work out, but as soon as the company has a change in strategy and we misalign, developers are often left by the wayside. This mirrors the world of dictatorships. If you could guarantee your dictator is fully aligned with you there is a good chance that the system will be far more efficient than a democracy. History has taught us though that 99.9% of the time this isn’t the case. The Open Web gives us an escape valve. It has its own problems and complexities (just as democracy), but that is all critically worth it.

Being “open” isn’t enough, and we need to have a platform that works for developers. We need to be able to make money. We need to be able to create amazing experiences for our users. The Web has a huge new challenge vis a vie the “app economies” out there, but it behooves us to all push the Web forward and make it work for us.

The Web has the opportunity to be THE unifying platform that can give us the best opportunities.

It is going to be an exciting and important few years. Now is the time to endeavor to help set some direction in the industry. I hope we can have an impact in our own small way.

As always, I am an incredibly torn individual after yet another Stevenote and recent Apple news. Apple is incredibly proud not just about what they manage to put into their products, but what they manage to keep out of them. Steve mentioned this again as he discussed the innards of the new Macbook Air products. The other example that comes to mind is their remote, which is laughable when placed next to TV remotes.

We have been opining for a long time about the obvious merge of iOS and OS X. For awhile people would argue about which side would win out, where “win out” means having the most DNA in the future. With Lion, we got just a glimpse on the next round of evolution. The first iOS DNA to get in is that of the app store (pre-Lion even), some look and feel (did you see the toolbar icons on the top of the Mac App Store app?), and the developer features around auto-save, resume where you left off, etc. Having OSX and iOS merge makes total sense to me. As much as I like the Mac, it is a workstation operating system. It was only when I gave my Mum an iPad that I felt like she felt safe and not scared of her computing environment. When I put on a certain consumer hat, I am so looking forward to the Mac App Store. Finally an install and discovery process that makes sense for my Mum. The Mac has arguably the easiest system, but even with DMG’s the process goes wrong every time:

“Wait, you have to double click on the DMG which will mount a drive. No…. don’t launch the app from within there you need to drag it out. No…. don’t drag it to the desktop, you have to put it in the Applications folder”

You can certainly argue that the controlled experience that we are about to get on the Mac will be good for consumers in a large number of ways. Apple is getting ~20% market share at this point, so they may be able to head the virus war at the pass by controlling the apps. And we can see what they have in mind with this control by looking at the review guidelines for the store Here are some of the functional guidelines:

• Apps that crash, exhibit bugs or do not perform as advertised by the developer will be rejected, as will be apps that are “beta”, “demo”, “trial”, or “test” versions. Apps that use non-public APIs or include undocumented or hidden features inconsistent with the description of the app will be rejected.
• Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them. Apps that are not very useful or do not provide any lasting entertainment value may be rejected. Apps that are primarily marketing materials or advertisements will be rejected. Apps that are intended to provide trick or fake functionality that are not clearly marked as such will be rejected.
• Apps that encourage excessive consumption of alcohol or illegal substances, or encourage minors to consume alcohol or smoke cigarettes, will be rejected. Apps that provide incorrect diagnostic or other inaccurate device data will be rejected. Developers ’spamming’ the App Store with many versions of similar apps will be removed from the Mac Developer Program.
• Apps must be packaged and submitted using Apple’s packaging technologies included in Xcode – no third party installers allowed. Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations. Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected.
• Apps that download other standalone apps will be rejected. Apps that install kexts (kernel extensions) will be rejected. Apps that require license keys or implement their own copy protection will be rejected. Apps that present a license screen at launch will be rejected. Apps may not use update mechanisms outside of the App Store.
• Apps must contain all language support in a single app bundle (single binary multiple language). Apps that spawn processes that continue to run after a user has quit the app without user consent will be rejected. Apps that use deprecated or optionally installed technologies (e.g., Java, [PowerPC code requiring] Rosetta) will be rejected.
• Apps that do not run on the currently shipping OS will be rejected. Apps that are set to auto-launch or to have other code automatically run at startup or login without user consent will be rejected. Apps that request escalation to root privileges or use setuid attributes will be rejected.
• Apps that add their icons to the Dock or leave short cuts on the user desktop will be rejected. Apps that do not use the appropriate Mac OS X APIs for modifying user data stored by other apps (e.g bookmarks, Address Book or Calendar entries) will be rejected. Apps that do not comply with the Mac OS X File System documentation will be rejected.

Wow, if we are both writing an application that does “the same thing” right now and I get it in the store before you, there is a chance yours could be blocked? I know that they are probably putting this in place to stop a million fart apps, but wow!

No way to handle beta apps and the like? Most of the apps that I run are actually beta (Chrome dev channel, Evernote beta, etc). At this point I would expect you to say “No one is forcing you to use the Mac App Store! You can buy and install apps just as you do now. Nothing has been taken away.” Absolutely, but it isn’t a huge leap to a see a future where this isn’t the case, and even in the meantime, it will be a pain to manage some apps via the store, and some outside of that process. It won’t be a great experience.

There is another way that the policies poke me. If we think back to when the iPhone came out with app support, they were actually more open than many of the alternatives. It was hell getting your apps provisioned on many of the platforms and the carriers had control. There is also a feeling of “hey, this is my phone, I really need someone testing things at my back as I can’t have my phone compromised in any way.” But on the desktop, even though these “devices” are all merging, it feels different. Feeling like the control is being taken from me feels weird. Do you feel that too?

Then we have Java. I actually wanted Sun to take over the OSX version of Java awhile ago, so it makes sense that the Apple team has deprecated its support. The Mac team was tiny and thus it wasn’t able to get much love, even though the engineers (we met them) were awesome. Now Oracle can hopefully step up and give us something great. This isn’t a great solution if you ship Swing apps (as my Mum won’t have Java installed, who knows if they will get anything that looks native etc), but fine if you are a Java developer who wants to develop on a Mac. I do wonder if any developers will reconsider Linux or even Windows as an alternative, and I am also thinking about what the Enterprise will think of this. For Apple, they have got rid of a support burden which didn’t bring them any great apps that they care about, and there is less of an attack surface area. Again, taking things out is good for Apple.

The much bigger news for Java fans is the fact that Java developers won’t be able to put their wares into the Mac App Store.

This may bolster the Web. Will the destiny pan out where it can be the unifying cross platform solution? For now, you can hopefully even write Cocoa apps using JavaScript, and of course the full Web stack is available. But what about the flip side?

I know. Those Mozilla hippies over-reacting again right. This will never happen. Apple loves the Web. How much do they love the Web as they need it (a) because uses want it, b) because it gives them a foil to the restrictions “look, we support the standard Web!”) and is there a chance we will be misaligned in the future? They may not cut Safari off at the knees, but what about a softer approach of not investing in WebKit as much (thanks for open source here!) and not shipping great versions.

If you look forward a few years and see that on the App Store they are bringing in 30% of revenue from their native environment, suddenly successful Web apps are losing them direct money. Hmm.

I think it is natural and smart for us to think about what is happening in the industry, and it isn’t fair to be called out as “over reacting” when someone brings up a “what if?”. We need to think critically. History has shown us time after time that alignments change.

That being said, Apple is building terrific product, and they offer real value to consumers (versus pure business lock in on crappy product, which we have seen in the past!). They have made computing so much better for so many people. They are providing opportunity for developers. They push the entire industry which is in such an exciting time. I can’t wait to see what happens next.

Where do we go from here?