Jun 13

The “I” in iCloud and the “We” in Web

Apple, Mobile, Open Web No Comments »

iOS 5 is a big release for Apple. It is their move away from the PC being the hub, and now we can talk to the big old iTunes in the sky. Android and webOS folk may scoff a little at this. “We have had over the air updates for ages!”, “Those notifications look familiar”, “In fact, my notifications are still far superior!”

It is great to see systems competing, and non iOS systems having advantages, but they shouldn’t get carried away. iOS is still the king. That is where the best apps can be found (ironically even though it is so restrictive), and the UI is still the most responsive and easy to use. Android is looking good and getting better rapidly, and is superior in real ways (e.g. navigation, deep integrations, etc) but again, it has room to grow too.

I was recently watching a tablet user study, and one of the users talked about how they thought that their tablet apps were so much better than the phone counter-parts. Really? Why did they think that? The reasons given were: easier to use, more stable, more responsive, and much more beautiful. Huh? Well, it turned out that this user had an iPad and an Android device. Ahhhhhh.

What struck me about the “cloud” side of iOS 5, was how it squarely goes after helping you manage your devices. The big pain point mentioned was getting content onto your laptop, tablet, and phone. What it lacked was the “we” part of sharing. I am very curious to see if this is a point of view, or a baby step. It is much easy to scale out the problem of “I”…. much easier to shard.

I have the pain that Steve mentioned with my devices, but I also have much more. For one, I don’t just have iOS/Mac devices, so how do I get them in on this action? For two, I have a family, and I want to help manage their world too. The tablet is a very social and shared device for some people. It gets passed around the family table. The same device could have your work email and calendar, as well as games for the kids.

One of the reasons that I bought an iPad 2 was because I could hide it, and the first generation could be the “family one”, leaving me my own. Now, you may think that Apple won here since I got a new device, but it feels natural that another tablet system will actually cater for the user here. I would be shocked if at some point in time, you don’t just pick up a tablet, the camera sees who you are, and you are shown your view into the world.

Beyond sharing a physical device, there is sharing data. Apple thinks in a very app-centric model (which has done very well for them!) and it is hard enough to share between apps, let alone beyond that.

Joshua Topolsky discusses Apple’s truth on the iCloud which hits this home.

While I won’t argue that Apple and others have had tremendous success with native apps and services, it’s also impossible to downplay the importance of the web and what it brings to applications. It’s not just that many of the applications we use are actually intimately tied to the web (even Apple’s own products are able to make quick changes like the switch to iCloud services in iOS 4.3 thanks to markup being used in place of native code), it’s that the web provides something native applications cannot. There is no native application for the Mac or iOS that replicates the shared document editing of Google Docs; there’s no mail application that exists for the Mac which will allow me to access my important information from anywhere in the world with or without a device in hand; there is no photo sharing service for iOS or the Mac which is as flexible or accessible as Flickr. When I need to access music with my Rdio account, I can do it from a plain old web browser, or an Android, iOS, or even BlackBerry application — and the ability to shift between those portals is incredibly powerful.

When it comes to Apple, it feels to me like the company views the web as a technology which undermines rather than enriches its products. It wants you to talk to the cloud, but only through its portals and its gateways, in closed loops and private networks. Is it possible that for the company Apple has become — the lock-in PC-maker, the gatekeeper, the retailer — there’s still a little too much Wild West in the web? Is Apple’s failure with or aversion to web services a byproduct of the desire for complete control over its ecosystem and products? Or is the gang in Cupertino just not that good at the internet?

The Web, though very simple standards (HTTP, URL, HTML, etc) is very much about connecting. This results in applications that can share data (even in the same UI such as mashups), and it is very natural to have a group aspect to the data. This means that we need permissions models around such data, and along with that we have the base APIs being built around URLs.

iCloud APIs on the other hand have an SDK that is built top down. The center of the world is Objective-C, now low level network primitives. This is a very different way to look at the problem, and you end up with obviously iOS-centric (if not “only” right now) views.

Wil Shipley himself links to questions on the Apple Dev Forum around how this system can work. The questions themselves can’t be questioned due to the restrictive systems in place.

There are a couple of social aspects of iOS shining through. Game center is one, but the biggest news here is the integration of Twitter, which is absolutely massive. Having the throne as the only integrated account (and most importantly, not having Facebook there) means that Twitter can take a huge run at social APIs that it maybe wouldn’t have cared as much about before hand.

It continues to be a great time to be in tech. Apple has made many small but important strides in iOS 5. Android “ice cream” is coming. And then we have the other mobile operating systems (Windows, webOS, etc) who are embracing the Web heavily.

When I think about the “we”, I definitely think back to my former thought that HTML5 is a jewel that we need to cut into a weapon.

Feb 21

Too greedy? A shift in the force

Apple, Mobile, Open Web 8 Comments »

apple greedy

The ripple effect from the Apple announcement on their 30% cut of subscription services is still going strong. Firstly, it is obvious that Apple has every right to do this.

The Readability folk wrote an Open Letter that plainly states:

To be clear, we believe you have every right to push forward such a policy. In our view, it’s your hardware and your channel and you can put forth any policy you like. But to impose this course on any web service or web application that delivers any value outside of iOS will only discourage smaller ventures like ours to invest in iOS apps for our services.

This is the heart of the matter for me. John Gruber started to poke holds in the article:

Maybe I’m missing something, but these guys claiming to be surprised and disappointed by Apple’s insistence on a 30 percent cut of subscriptions when their own business model is to take a 30 percent cut of subscriptions strikes me as rich. And how can they claim that Readability isn’t “serving up content”? That’s exactly what Readability does. What they’re pissed about is that Apple has the stronger hand. Readability needs Apple to publish an app in the App Store. Apple doesn’t need Readability.

This side steps the main issue. It isn’t about the right to take the 30%. The problem is that some of the companies don’t have a business model that fits this change. It especially hurts models that pass money back to another entity. Even a pure model such as 37signals Basecamp would need to do the math on what 30% of their monthly fees would mean to their bottom line. Add to the fact that the iOS price has to the lowest means that all prices may have to change.

And then there is the infrastructure. You can imagine that it would take some effort for Amazon to build an in-app purchasing system, and this is work that takes away from building out other infrastructure. I know, they should just suck it up.

However, at a time where iOS and Android competition is at its strongest, Apple makes a change that alienates developers and businesses. Apple has always had an interesting relationship with developers. There was the 3.3.1 issue, and the general fact that they are very closed. However, even with all of that, developers could understand it. The 30% though feels like too much greed. Oh, come on, I hear you say. How much does the retail chain charge you as the middle man? This is a great deal! “Apple has brought back the shrinkwrapped software business!”

30% is changing the tide though. Many of these companies will be looking much more strongly at other platforms, and investing in those platforms (Android, Web, and maybe others).

John thinks that “Apple doesn’t need Readability.” It isn’t about not having one app. The balance in the ecosystem is changing. Many of the Big Apps will be investing more elsewhere than before.

Maybe this will blow over and the iOS ecosystem is so strong that it doesn’t really matter. Maybe Apple will see that it has gotten “too greedy” (not that they don’t have the right, but that it isn’t worth the hit to the ecosystem) and will lower the % or make other changes for different types of subscriptions.

It will be interesting to see. It definitely feels like there is a disturbance in the force.

Update

Chris Leydon has commented saying that:

We have no issue whatsoever with Apple taking a 30% from our app… they just won’t provide us for the means to do it and inadvertently lock us out from the app store.

A bulk of the TinyGrab post goes into detail on how they break various infringement numbers and how, because of limitations in the AppStore, they can’t do business there. One key item is the fact that you don’t get info on the purchaser (and thus without having that connection you can’t do things like offer free access via another app), as well as other items around “rental” and unlocking features. If you want to get creative (or just offer simple use cases for your users!) with the way that you do business, you may not be able to work within the Apple system.

Jan 20

HTML5^H: What it means to developers, standardistas, and browser vendors

HTML, Open Web, Tech 7 Comments »

html5logo525

As soon as you read HTML is the new HTML5 from Hixie, you knew that it would be fertile ground for people to discuss, argue, tease, and ridicule various sides… especially with this coming from WHATWG days after the HTML5 logo was unleashed by the W3C.

On one side you have people looking at the notion of a standard being alive as bizarre. Isn’t the point of standards to be able to say that multiple implementations support something in the same way?

On the other side you have people that say that the notion of a versioned standard on the Web doesn’t make any sense. How many browser implemented CSS 2.1 to the letter of the law?

What do developers want to see? The ability to know what capabilities they have at hand.

How do they work together? How can they be polyfilled? How uniform are the implementations?

This is a massive pain point right now. What does it mean to write an HTML5 experience? Some parts of HTML/CSS/JS are very well baked. Others aren’t. Developers have to work a lot of this out, and the community has built sites like html5readiness and tools like Modernizr.

In practice, to do something truly cutting edge, you have to do a ton of testing on various browsers. You want to just use CSS3 hardware transforms, but you find out that there are drastically different implications on desktop browsers, and when you get to mobile browsers the game that much more. Then there is hardware acceleration of Canvas on some browser/platforms. This goes on and on and on.

Cutting edge alpha developers can maybe keep up with some of this stuff, but Joe the App Developer may not be able too, and nor should he.

Wouldn’t he rather use a platform like iOS that has a very clearly versioned SDK that he can develop to? Surely that is much less painful.

There are trade offs though. In iOS, you have to wait for a beta SDK to play and find bugs. You are much further down the process that the Web, where you can step up and be much more active. And Web developers need to step up to be much more active. We need to be talking to browser vendors about what we need in the Web platform for it to compete, and for us to be able to deliver the experiences that we envision. We have the ability to influence our platform, so let’s make that trade-off worthwhile and not just sit and see what a particular standards group or browser vendors shows us.

I very much want to give developers a great way to see what they realistically build against on the Web platform. However, although the world took up the “HTML5″ mantle as the next “Ajax”, the HTML5 isn’t the right standard for this to play out. It has never been natural, because the Web platform is much more than “HTML”.

In fact, isn’t it ironic that “HTML5″ has become “a platform to build amazing Web applications” when much of the HTML5 spec started out by adding new tags that deal with document structure and not applications at all! sections. authors. navigation. headers.

Hixie mentions the Web Applications 1.0 specification. Something like this is more appropriate as a specification that can say “these are the things that the Web platform will give us”. Allow the HTML group to iterate in a way that they see fit, but out of that chaos we need something that can give an ordered solution to developers. And, if we have the “living standard”, we need the “living tests” that we can be continuously running on browsers. The tests will arm us with knowledge on a) how to use the APIs in many use cases, and b) tell us when regressions kick in.

So, we need to give developers a set of capabilities in the Web platform that they can rely on. What about the marketing angle?

HTML5 was laughed at by many practitioners, but it has traction with execs. They see HTML5 as a way to deliver cross platform solutions, as a way to get new disruptive experiences out to their users. The term is useful in many ways. Authors can write books on HTML5, but how do they write them on “HTML”?

In short, maybe we need some changes:

  • We need a clear vision on where the Web platform is going, and how everyone can be involved.
  • We need some notion of documenting what the platform as a-whole can do (thus: we need versions). Just as an iOS developer can see what 4.3 beta, we should have something similar. This will be an umbrella of smaller specs and versions, but we need something.
  • We need rich tests that we can run against Web platform runtimes so we know what they have implemented from the platform standard
  • We need to acknowledge the needs of multiple parties that keep the Web moving

Whether or not the HTML spec in the WHATWG is called HTML5 doesn’t really mean that much in the big picture. We need to solve the bigger problems. I hope that we don’t spend our time arguing over the politics of this or that, but on where we should go from here.

Dec 15

Chrome Frame for iPhone; Taking your HTML5 renderer with you

Mobile, Open Source, Open Web, Tech, Web Browsing 2 Comments »

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

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? ;)

Dec 14

If Chrome OS perishes or even merges, it will be a sad day for the Web

Google, Mozila, Open Source, Open Web 4 Comments »

People have often commented on how strange it is that Google has two OSes in Android and ChromeOS. Some talk about how it is doing the “Microsoft thing” by setting up an internal competition, and Google is big enough to do that kind of thing.

There were many who saw that “the Web will eventually win”, but as Android’s numbers get larger and larger, others are pondering things. Is the timing off? Has Android gotten too large to let itself lose to Chrome OS? Is the app ecosystem for Chrome OS not up to snuff with Android (let alone iOS)?

If Google pulled the plug on Chrome OS it would feel like a bad day for the Web. Chrome OS needs push the entire Web forward. Chrome is adding features to WebKit and Chromium at a very healthy rate, and the Chrome OS pieces make sure that features that flush out the Web to rival native environments come along. Without the Chrome OS project being part of the whole Chrome ecosystem, that may not quite be the case.

There are some projects that Google should go long on, and some that should be experiments. You could argue that Wave was an experiment that didn’t warrant continued evolution, but Chrome OS should. It moves the Web forward.

The Web has a lot of huge benefits, but it is still hard at it going up against iOS, Android, and others. We need a lot of investment to give the Web the SDK that developers are striving for, so they can deliver compelling experiences. We aren’t there yet.

With Google and Chrome OS, HP and webOS, and even a lot of other players (e.g. RIM and its Web support, Nokia and its, etc etc) we are seeing a healthy double-take on taking the Web forward and making the next big platform truly multi-vendor.

“Merging” with Android is interesting. Android’s web stack has gotten better recently, but it is very much lacking, and you could argue that getting the Chrome/WebKit talent and putting it on the Android stack could do a lot for the Web, and maybe bring the Web up to be a true Android platform. That could be a good thing, but would it ever truly be a first class citizen compared to the “Java but not really Java” stack?

I truly hope that Google double downs on Chrome and Chrome OS, and gives it time to have the Web come along for the next ride as more than the ghetto that some would like to see it become.

If not, time for Mozilla to create a Web OS :)

Dec 02

Native apps are always better than Web apps; Psst, the new way has an escape chute

HTML, JavaScript, Mobile, Open Web, Tech, UI / UX, iPhone 3 Comments »

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:

Apple - old and new

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!

delta-casestudy1

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:

delta-casestudy2

delta-casestudy3

delta-casestudy4

delta-casestudy5

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

Nov 19

Not only are URLs special, but yours is too!

Mobile, Open Web, Tech 2 Comments »

available on the app store

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.

delta-downloadtheapp

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.

Nov 12

URLs are special; Where the Web beats Native

Open Web, Tech 3 Comments »

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!

Yahoo! - old and new

A design heavy company such as Disney:

Disney - old and new

And also Apple:

Apple - old and new

And, finally, we tease Google a little:

Google - old and new

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.

Oct 31

“Our strategy with Silverlight has shifted”; The problem with alignment with a single vendor

Open Web, Tech 4 Comments »

mobilechangeinmarketshare

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).

scottgu silverlight

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.

Loading...