techno.blog("Dion")

Ben and I, and the entire Set Direction team are now part of Walmart. We are now leading the mobile engineering effort and have set off on a journey to revolutionize mobile commerce at the largest company in the world.

Now, you may be a touch surprised. “You just started!”, “Walmart?”

To be honest, if you had told us that our career would take this turn 5 months ago, we would have been surprised too.

Here is what happened. After leaving Palm/HP, we had some hypotheses around the difficulty that developers were having in a modern world that contains a diversity of platforms. Not too long ago, most businesses were building Web sites, and the diversity was around the number of Web frameworks. Many companies are now in a post-Java malaise and there are a huge number of very viable server solutions for developers to choose from.

On the client, you need a Web presence, but may also need to get onto iOS, Android, and even Blackberry, WinPhone, webOS and friends. These new platforms are amazing for developers in that they come with low-friction monetization affordances, but they are very different technically. The Web has the opportunity to be a great cross platform solution (again!) but there are real trade offs between Web vs. native, and it very much depends on the type of experience you are going for, your business needs, and even your personnel.

We set out to explore the entire stack, from the clients all the way to service creation that fits in to the unique needs of mobile. To test out the hypotheses we took on a small number of clients ranging from small startups to the Fortune 50. One of these clients was Walmart where we teamed up with Paul Cousineau (former product director for webOS), someone we rated highly from our time at Palm.

We quickly learned that Walmart was very serious about a quest to use the mobile revolution to make commerce a fantastic experience for their customers: whether that is helping to get the most out of their store visit, or buying goods from Walmart.com (or the many worldwide properties that are part of the Global eCommerce group). We had conversations with executives all the way to the top, and we heard a strong message: there is a belief that the advent of mobile could be larger for commerce than the years where the automobile enabled true reach to even rural America…. a time that launched Walmart on its path to the top.

We got to know other members of the team over the last few months, and a conversation started around Walmart acquiring the Set Direction team to accelerate their vision. We had discussions about the way that we think product should be created, about the role of open source, on how we like to build teams, and Walmart was very much aligned. They really want to build something special here.

This all culminated with us signing up to build a world class mobile group, backed by the fantastic resources of Walmart. We are joined by some other new faces. The Kosmix crew are top notch engineers with careers building mechanical turk, various search engines, and most recently a real-time social genome. Social and mobile can fit hand and glove, and we are very excited to work with them as part of Walmart Labs.

What does this mean for our other activities?

• We recently launched FunctionSource to cover the Web and mobile space. We have a passion for being part of the community and that won’t change. It has been fantastic to get back into the game post-Ajaxian, and we look forward to doing some fun experiments on f{}. We will be open sourcing the technology behind it, which includes a particular fun “view server” that allows us to enjoy writing the application using CoffeeScript, Backbone, and modern client Web technology…. but serializing that out to “legacy” browser such as…. the Google Bot.
• Conferences? We love being part of the community. That can be on Twitter, FunctionSource, but very much speaking and participating at conferences and user groups. We have a lot of exciting work to do at Walmart, but we want to share some of that with you and learn from you too!

We have a mammoth task to make the most of the amazing devices that consumers have, and the massive amount of data (internally from Walmart itself, but also externally across the Web). We want to build delightful products using the best technology possible. Walmart also has a global reach, so we need a developer platform that scales.

I am obviously excited to continue to work with my friend and long time partner-in-crime Ben Galbraith as we take on this new challenge. Here you can read his thoughts on our new roles.

Finally, we are looking for like-minded developers to join us on this mission. If you look to take on some hard problems using leading technology surrounded by fellow technologists, we are looking for people like you. We care equally about: the craft of software, building great products, and having great fun along the way.

You will have access to real scale. Our iOS application has millions of downloads, and we recently released an Android application that jumped into the top shopping applications list in short order. And of course, don’t forget the mobile website, with an epic number of users as customers. We have big plans for that experience.

Please reach out to talk more about joining the team.

There has been another rise of the “can we trust the cloud!” type articles recently. They normally come from two perspectives:

Consumer

“See what happened with Sony! Nothing is safe!” Or, “can you really trust your data on a cloud such as Google’s? If you use a Chromebook and everything is up there, you are just a subpoena away from the government seeing that data!”

There are valid issues to think about, but we also quickly forget the last time the hard drive crashed and your data was lost.

Enterprise / Companies Building Software

The Amazon meltdown sent shocks around the Web on this one. A friends company had just migrated from their own servers to Amazon and suddenly the business was wondering if that was a smart choice. Much like in the consumer space, we often forget about the time that someone hacked into your operations, or some other issue occurred.

The thing is, if you can help it, you should trust any one thing. If you are on a “cloud” make sure that you are in multiple regions.

The LearnBoost crew were one step ahead of the Amazon issue and posted about their redundancy, how they used regions, and how they used mongo replication to make sure the data was there.

Ideally though, you should think about going beyond one provider. At some point it would be nice to have insurance policies between these providers so you can hot swap if there is an issue.

This is why I was a fan of CloudFoundry when I first heard about it from the VMWare crew a few months back. They have managed to provide a stack that is high level enough (e.g. you have apps and services and you choose how they talk together) but open in many dimensions: you can use different languages, platforms, and frameworks….. but the core underlying system is also able to run on multiple clouds. This is huge. One chap wrote a piece on the fact that open sourcing the system is a gimic, but having vcap out there has enabled a slew of people to port it on top of their systems.

At the end of the day, this means that I can run on top of vcap with my nice vmc scripts, but behind the scenes I am a mere vmc target othercloud.com away.

We haven’t talked much about how we use CloudFoundry for FunctionSource, but it has been a real pleasure and we are early customers! Being able to vmc instances +10 makes me feel like I am in the future, and the developer ergonomics are very strong. I love being able to cd into an existing node app and vmc push the puppy up in a second.

The cloud isn’t a silver bullet, but being able to seed network and sys-admin duties has been a pleasure. Thanks to the open source nature of the product, the core system runs all over the place (including on Amazon) which means I can get my redundancy and failover with massive pain.

Feels like the best of all worlds…. the cloud is here to stay folks, just give yourself some backup.

I enjoy learning new languages. I am not on the yearly diet as the Pragmatic folks would desire, but when I can…. I enjoy expanding my mind as I have definitely experienced the fact that learning a new language makes me program differently in all of my other languages.

Clojure and Scala are interesting to me in the land of Java, but that isn’t where I have been spending time (until recently). I have been very much enjoying Jeremy Ashkenas’s CoffeeScript. What’s not to like? Jeremy has managed to create a language that cleans up many of the issues in JavaScript, and codifies much of the Good Parts into source form. Ruby is my favorite language, and this gets really close to my ideal mental model.

When talking to Brendan Eich about the language, he very much appreciates it, and also the fact that it maps nicely to the JavaScript model (versus something like GWT and Java mapping on top of JavaScript say).

In some ways it feels bizarre to write in a high level language which gets converted to another high level language. One thing that has been enjoyable though is learning this language. The killer features for me are:

• Jeremy takes care of things like documentation. The main site is the best introduction and documentation for any language.
• Source code as byte code. I don’t enjoy reading byte code. I do enjoy reading JavaScript code (a language I know well) though. It is fantastic to be able to play with a new language and instantly be able to see the JavaScript output, whether it be small things via the inline site, or via -w / cake watch.

One feature that I am not a huge fan of is the pythonic importance on significant whitespace. Notice the image above, and how the ordering of elements made a difference to the output.

It is very cool that Firefox is going to “natively” support loading up CoffeeScript, and I think that someone needs to create Coffee and do to Java what CoffeeScript has done to JavaScript.

You could argue that this has already been done….. Groovy? Oh and thanks to the great work of Charles, Tom, Ola, and friends…. I can even use JRuby over there…..

2011. HTML5^H. JavaScript everywhere. Cross platform mobile. The “Post-Java malaise”. The user experience bar.

It is an exciting time to be developing software. We have multiple stacks that make building the server side easier, and we are on the precipice of pushing into real Ajax. Real modern clients. We are going beyond the world of sprinklin’ some JavaScript into an HTML page.

Progressive enhancement used to be the only viable option because most (by percentage) of the browsers hitting your site kinda sucked. Thus, it made sense to give them an experience of some sorts but enhance that experience for those that could deal with it.

Now, we even have a decent browser from the IE family. It feels like the days of IE5 :)

Since the tables have turned, we then get this crazy idea that we can build for the rich majority…. and regressively degrade for the poor buggers who aren’t able to up their browser due to crazy IT departments or illegal Windows versions. Lord of the shims and polyfills. We have been doing some fun work to make this work in an automated fashion, but that is for another time.

When you start building applications on top of WebSockets (and degrading) you also start to think about different architectures. WebSockets gives us a rich, fast, bi-directional pipe between the client and server. Whether you are a Socket.IO lover with Node++, or an Enterprise sort on Kaazing, you can start to deal with a very simple messaging API (that degrades).

Suddenly, you are building with a rich client MVC framework (enjoying Backbone and the like) but instead of mapping back to REST (which Backbone makes easy) why not deal with publishing and subscribe to topics?

No more polling. Instant real-time. These messages can piggy back and even go straight to the land of MOMs (JMS, Stomp-iness, etc). Now on the server you have loosely coupled processes that consume messages and do their work. Scaling out with a loosely coupled messaging infrastructure is so much easier to deal with that RPC madness.

I am having some fun with this type of infrastructure, and I am curious indeed to see where it leads. You?

The iOS Twitterati came out in full force once once they had upgraded to the latest 3.3 version. The new version has a ton of great features, such as autocompletion of @usernames and hashtags, better photo uploading, and some UI cleanup. This has all been over shadowed by the addition of a “trending topics” bar that appears at the top of your view.

I am sure that some users love the feature (the quiet ones) but a vocal community quickly came about and:

• a) complained
• b) reverted to 3.2 or even to try other clients (e.g. Echofon)
• c) built and installed software to “fix” the issue (e.g. Twizzler).

Those who are vocal wanted a way to turn this off. An option. Even if it is buried in the settings (a few taps into the app).

To this, Dick Costello (CEO) responded:

This is very interesting, and where we can learn. I have found that one key art in software development is when and how to abstract your code. I have seen developers go down a common path:

• Phase 1) Minimal abstractions. Spaghetti code ensues. Everything is coupled to everything else
• Phase 2) Crazy abstractions. Ravioli code ensures. Everything is wrapped as one method with an abstract class and an Interface (picking on Java here!)
• Phase 3) The balance. Working hard to make the right balance, enabling readable and modular code without losing the ability to see how it all fits together.

ASIDE: I tend to enjoy the like of Ruby (and even JavaScript and CoffeeScript) as I always feel like every line of code is doing something.

There is a similar balance in the world of UX. You want to offer just enough knobs and switches to get people working in a beautiful way, but not too many (so they can’t work out how to do a darn thing [e.g. original desktop linux days]) or too few (so they feel like they can’t get anything done!).

I find it fascinating to watch this balance. As a power user, I find it interesting to know what I personally want to be able to tweak about a system. For example, going back to Twitter. I switched to Echofon from Tweetie back in the day. I loved much about it:

• The way that you click on something and a gutter shows you more, but you don’t lose your context
• It was an early consumer of the streaming API so data showed up sharply
• It showed when people interacted with my tweets (other RT, favorites, etc).

One feature that people will scoff at as minor, is the fact that it has no way to display the real name of the tweet author, and instead I am stuck with a username. Now, I happen to have a bunch of folk who I follow who have fun handles. However, I don’t have the full mental map to remember that @monkeyape23 is my old mate Bob from England. I just want to see his name. Please. This silly little feature lead me away from Echofon believe it or not (please add it guys!).

I liken my Twitter client to my Email client. Some people love their stock Gmail/Mail.app/Outlook experience, but many very much like to tweak it. Some may want a three-pane view (I use “Multiple inboxes” on Gmail for this), some want to change the number of lines in the preview, and others trick the hell out of their system with scripts and extensions. You are in this software daily, and some folks like to sharpen their tools.

Now, I get that the official Twitter client is a “base level experience”, but that doesn’t mean it has to be simplistic and rigid. I also find it hilarious that, although there isn’t an option to hide the Trendbar, there IS an option to turn pinstripes on and off :)

You can easily go too far with “options” as Alex Faaborg (Firefox UX…. highly respected) mentions:

Now, I mentioned extensions above. This is another important thing to think about as a release valve for your users. Firefox took something that “had too many options” (Mozilla Suite) and stripped it to something much more bare bones, but XUL/XPCOM were still there (and even about:config was good in that extensions could target it). Developers could create fantastic additional experiences that users could enjoy. To me, this was one of the key items of Firefox that made it #winning in the old days. IE actually had add-ons too, but they were painful to write and the platform was nowhere near as approachable and available. We got amazing functionality such as Firebug and Greasemonkey.

Ah, Greasemonkey! The Web turns out to be a fantastic extension platform. When I load up twitter.com itself, a few Greasemonkey scripts kick in for me to customize the experience, and I get things how I want them. You can mine for great user scripts out there, and now that browser such as Safari and Chrome also not only offer extension support, but do so in a very HTML (and Greasemonkey) friendly way, you will find them packaged there too. Chrome and Safari had to create extension systems to compete. How many of you waited for that one extension to full switch from Firefox to Chrome?

In my ideal world, Twitter would not only add an option to get rid of the #dickbar, but would also offer an extension API that would enable folks to build extensions that flow from their awesome communication ESB in the cloud, all the way to the client platforms that access it.

Our users are human and have different needs. It is fine and dandy to want to “do a Steve Jobs” and create something that is so perfect that you can hand it down to the fellows, but how about a one-two punch. A fantastic default experience, with hooks to enable developers to offer up fantastic experiences to your end users.

I couldn’t move to Chrome without Adblock and ….

I can’t move to Sparrow until Rapportive is supported.

If you create a great plugin system, there will be no reason not to move on. #thewebrocksatthat #firstworldproblems

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.

Brendan Eich just spelled out the Harmony of his dreams. A state of the union from the language creator timed for when the ECMA TC39 group gathers to hopefully move the ball forward.

This post made me very happy indeed. Over the years I have gotten to the place where I actually really like JavaScript. There are other languages that I may prefer, but I am at peace with JavaScript and its frustrations.

Variable hoisting and this.foo all over? Crazy, but I am fine.

var self = this; or .bind(this)? Whatever.

Module system is tied to script tags? Worked around.

I was right there with ES4 back in the day, hoping to see a bunch of improvements finally getting in to more than Firefox’s type=”". Then the wheels on the bus came off. There were great additions / changes / clarifications, but the typing and namespaces/programing units/packages features? It went just too far.

JavaScript put its tail between its legs and we had to cheer for the small wins of bind() and create(). Fortunately there were huge wins at the VM level. Modern VMs are fantastic, and paved the way for server side JavaScript with Node…. after all of these years.

We need more. There is a responsibility to backwards compatibility that is always brought up. That is important, but there is also a responsibility to moving the Web stack forward. JavaScript has become the glue and power tool of the Web. In theory you can use that type=”" to do more, but getting all of the browsers to implement a language isn’t going to really happen, so we are stuck with JavaScript for good and ill, for the foreseeable future. Let’s make it great.

So, this is why I am so excited to see Brendan talking about how to do just that. There are some classic lines in his post:

You can do anything with function in JS, but you shouldn’t have to — it over-taxes JS programmers and VM implementors to learn and optimize all the idiomatic patterns. Too much like writing with only one-syllable words.

…

I agree with Doug that tail calls would be a win, especially with evented code. The # function syntax allows us to give tail calls a boost and save you seven (14 total: function + return_ – #) keystrokes.

…

Why not bind this to the same value as in the code enclosing the hash-func? Doing so will greatly reduce the need for var self=this or Function.prototype.bind, especially with the Array extras. It’s great that ES5 added bind as a standard method, but why should you have to call it all over the place? If Harmony does not address this issue, I will count that a failure.

…

A hot-button issue with ES5: Object.freeze. Whose side are you on, Batman’s or Mr. Freeze’s? Simplistic to say the least, since even in one’s own small-world codebase, making some things immutable protects against mistakes. Never mind single- and multi-threaded data sharing and other upside.

…

The simple modules proposal, along with its module loaders adjunct, is the likely Harmony module system solution. Note that there is no left-hand side example written in current JS below — you’d need a preprocessor, not part of the language.

Closing Remarks

This is a long post. If you made it this far and take away anything, I hope it is Guy’s “Growing a Language” meta-point. JS will be around for a very long time, and it has a chance to evolve until its users can replace TC39 as stewards of its growth. The promised land would be macros, for syntactic abstraction and extensibility. I am not holding my breath, but even without macros, the Harmony-of-my-dreams sketched here would be enough for me.

We aim to do more than dream. Narcissus is coming along nicely since it moved to github and got a shot in the arm from our excellent Mozilla Research interns last summer. We are prototyping Harmony in Narcissus (invoked via njs -H), so you can run it as an alternate <script> engine via the Zaphod Firefox add-on.

@andreasgal has a JS code generator for Narcissus in the works, which promises huge speedups compared to the old metacircular interpreter I wrote for fun in 2004. With good performance, we can actually do some usability studies of Harmony proposals, and avoid Harmony-of-our-nightmares: untested, hard-to-use committee designs.

A code-generating Narcissus has other advantages than performance. Migrating code into Harmony, what with the removal of the global object as top scope (never mind the other changes I’m proposing — here’s another one: let’s fix typeof), needs automated checking and even code rewriting. DoctorJS uses a static analysis built on top of Narcissus, which could be used to find flaws, not just migration changes. Self-hosted parsing, JS-to-JS code generation, and powerful static analysis come together to make a pretty handy Harmonizer tool. So we’re going to build that, too.

More on Narcissus and Zaphod as they develop. When the time is right, we will need users — lots of them. As always, your comments are welcome.

I am sure some programmers will feel like they just read Crock’s good parts and finally get JS…. and now it will change? I remember the days where my() seemed so foreign as I put on Perl5 (and it took me a bit to really grok my vs. local [and we have var vs. let now]). There are so many times where I dislike change, but then in time the changes become habit and I wonder how I lived on the other side.

It is time to re-tool.

I am finding that I really enjoy CoffeeScript. I find it fun to use. I am happy when using it. If core JavaScript can give me much of that, I will be very happy indeed.

I may disagree with some of the TC39 decisions, but I just hope that they make a big push to do bold things at this time. The time is now, and it is great to see signs of hope:

Good news everyone! typeof null == ‘null’ might actually happen.

I recently talked about the attack of the mobile browsers.

Then, Steve shared bookmarklets for mobile performance work.

He and Jesse hosted a fantastic Velocity Summit in the city today with the best and brightest in the realms of web ops and browser land combined. It was an honor learning from them, and it was just fantastic to see top notch folks from Chrome, Firefox, IE participating and sharing ideas.

With all of the performance talk, I started to play with Steve’s work, and was reminded how much of a pain it is to work with bookmarklets on iOS. There are some solutions, from Dropbox, to syncing bookmarks (from iTunes as well as Firefox Home), but in general it can be a pain.

Some of the new iOS browsers have extension support though… such as the 360 Browser. I wondered if it would be more efficient to great extensions (they call them plugins, but that confuses the world with Flash etc) that are quickly actionable from within the browser. Ideally, I could tell the browser to always run the extension so I could collect data throughout a session.

One concern though was the fact that most users on iOS are coming at you from Mobile Safari, and although these new browsers are using the iOS WebKit APIs (as Apple won’t let them do anything else) how different are the browsers themselves?

BrowserScope to the rescue. I fired up and ran all of the tests in each browser application and compared the results. They were incredibly consistent. All of the numbers were the same when run on: Mobile Safari, Sleipnir, 360 Browser, and Skyfire except for the “Cache Redirects” test in the Network section. In that case, two of the browsers passed the test and the other two didn’t. All in all that is pretty friggin’ consistent though. The network connections were all the same for example….. so this makes me feel like there is room for a nice developer oriented iOS browser. Sure, it can’t get access to a lot of the low level data, but there is much that can be done, especially if you pair it with a remote session ability so you can power the beast from a desktop rather than the dinky device itself!

There has been a ton of fire on the Internet around the news from Google that it is dropping support for H.264 from the Chromium project. I think that this is a great example of how the way it was messaged could have really hurt Google.

A core issue that Google has is that now it is large, people read many things into its actions. In the case of video on the Web, who rules the roost at Google? There are many parties that have skin in the game in some way:

• YouTube delivers a fair amount of video on the Web
• Google Chrome (browser, OS, etc)
• Android
• Google TV
• Google Voice
• GChat
• … and the list keeps going and going!

I love it when people editorialize only one of these heads. For example, this piece on how the whole thing is actually just about YouTube and their costs. YouTube is only one player.

The key problem is that Web video is friggin’ messy. The Web loves openness. Users love functionality. We are in a period of time where the two aren’t always aligned, which ends up with many people having to double encode and support multiple formats.

Also, both sides of the argument love to talk to extremes, but the lines can be a little grey.

For example:

• Some people wrote about how Firefox is doing great in Europe which is a huge market, and thus everyone will be doing WebM. Erm, there are lots of other markets with millions of people where that isn’t supported.
• Others say that WebM handled as part of a standards group, and thus “it isn’t an open standard! H.264 is!” WebM is licensed very liberally indeed, and is in a position to be very much an open standard. To put the nail in this coffin, it would have been fantastic for Google to have come out with a message that talks about plans for standardization and what they are thinking.
• “Google should stop delivering Flash!” On one side people say, “Come on. Flash is ubiquitous enough that Chrome needs it to be a competitive browser. The battle here should be to move the Web fast enough and add capability which means that plugins aren’t as needed for certain situations.” If you care about DRM and other items in video, you may wish that you can use <video> but you can’t yet. The other side will say “Google is being disingenuous with their use of the ‘open’ word 8 times in their post.” Again, I do think that the communication could have been clearer from them, and they could have explained much more why they are doing this.

In general, that post comes from “Mike Jazayeri, Product Manager.” Who is that cat? Where are these thoughts really coming from? Is it from an On2 guy looking to fight the fight? from a policy person? from YouTube?

Sometimes it is how you say it, and I think Google could have done a much better job getting their partners briefed and unified proactively, and a better job in explaining what they are really doing. A group like Mozilla can make a much more respectable argument based on the grounds of openness and the long term. Asa is out there fighting the good fight right now in fact (commenting on this great post by Haavard@Opera):

In 6 months time, of the HTML5 capable browsers, Firefox, Opera, Chrome, IE9, Safari, more 2/3rds (by usage stats) will support WebM exclusively and less than 1/3rd will support H.264 exclusively.

H.264 is not winning when it comes to HTML5 video support. WebM is winning. Actually, it’s more than just winning; it’s kicking ass.

Now. Back to an incredibly messy world of video. It isn’t about the number of HTML5 capable browsers. There are a few phones that support H.264…. and although hardware support is coming soon for WebM, it aint here yet, and the majority of content isn’t encoded in WebM. This is all great news for companies such as Brightcove who get to leverage the pain that we all have in the (hopefully) transitional phase to an open world for Web video.

Updated Google saw the commotion and I am glad to see that they joined the conversation and gave more information in this clarification.

It has been exciting to see the increase in mobile browsers available for various platforms. Some platforms have allowed this freedom (e.g. a “full” Firefox experience on Android). Others like iOS restrict applications to the realm of WebKit and the APIs available:

“2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript”

Even with that handicap, we have seen some very interesting experiments, each with their own take.

I have been playing with some of the new iPhone browser apps recently. What jumps out at me?

My favorite is probably the 360 Browser from Saloni Srivastava. It packs a lot of fun features into a small device sized package, even if the UI feels a little foreign sometimes:

• The pie menu approach brought a smile (we experimented with a pie menu in Bespin). There are two modes: drag and tap. With the default drag mode you end up holding a digit down on the screen and moving around. In practice I found this approach wanting because I would either hide the menu that I was aiming for, or I would move off and the menu would disappear. I prefer the tap approach, but actually wish for a solution that mixed the two… specifically, in tap mode I want to be able to hold down on a menu item and have a tooltip tell me what I am dealing with…. important as you learn the system.
• Firefox Sync support is fantastic. I wish that I could tie in syncing from other browsers too and unify things.
• In the top left of the toolbar you can quickly tap to make the current tab private…… something that many users will enjoy ;)
• Tab support in general is good, and you can quickly show and hide them
• Which leads into full screen support
• The plugin system allows you to bring in a lot more to the experience. It feels a bit clunky, going into the plugins area and tapping on the item even though it has an [x] on it etc, but it great to be able to extend your browsing.

Sleipnir Mobile innovates nicely with tabs and somewhat with tagging and bookmarking. Being able to setup various “workspaces” for your tabs is very useful. I find myself wanting to keep a copy of sites like TechMeme, Hacker News, and others, and being able to put them in one tab group is fantastic.

Skyfire has both an iPhone and iPad version of their browser. Most talk about their support for Flash video, but they also have other interesting features such as their “quick views” which give you a taste of Twitter or Facebook without having to jump away from your current browsing stream. I am not the kind of chap who is looking for “related” exploration, but others probably are. It is also interesting to see how browsers get around limitations of the app-centric model. For example, Skyfire is aware of the clipboard and sucks in URLs, since you can’t send a URL to open that browser, or have a system-wide setting for “default browser”. We have similar issues with bookmarks. I want one central store that they can all use (others would like separation).

In general, features such as private browsing, better tab management, and also caching itself can be huge. It drives me bonkers to hit the back button and have to wait for a page to be reloaded when I just came from there. I would happily give up a lot more hard drive space on my device to the browser. The feel of the browser is important too. If the scrolling is off, or the gestures? Ugh. I had that experience with Opera when it first came out. By default pages were zoomed so far out that it was unreadable and the pinch/zoom felt wrong.

I really hope that the exploration that is happening in the mobile browser space (and the money that some folks are making off of it!) keeps going, and that Apple opens up their terms to allow for a full Firefox experience and others.

What would you like to see on a mobile browser?