Posts Tagged‘html5’

The Viability of Cloud Gaming.

The idea of cloud gaming is a seductive one especially for those of us who lived through the times when upgrading your computer every 12 months was a requirement if you didn’t want to be watching a slide show. Abstracting the hardware requirement away from the user and then letting them play on any device above a certain, extremely low threshold would appear to be the solution to the upgrade and availability issues of dedicated gaming platforms. I’ve long made the case that the end product is something of a niche market, one that I was never quite sure would be viable on a large scale. With the demise of OnLive I could very easily make my point based around that but you can never write off an industry on the failures of the first to markets (see Iridium Communications for proof of this).

Providing even a small cloud gaming service requires some rather massive investments in capital expenditure, especially with the hardware that’s currently available today. For OnLive this meant that only one of their servers could serve one of their users at a time which was terrible from a scalability point as they could never really service that many customers without bleeding money on infrastructure. For cloud gaming services of the future however they might be in luck as both NVIDIA and AMD are working on cloud GPUs that will enable them to get much higher densities than the current 1 to 1 ratio. There’ll still be an upper limit to that’s much lower than most cloud services (which typically serve thousands per server) but at the very least the scalability problem is now an engineering issue rather than a capital one.

The second major challenge that cloud gaming companies face how latency sensitive a good portion of the games market is. Whilst you can get down to very low latency numbers with strategically placed servers you’re still going to be adding a good chunk of input lag on top of any server latency which will be unacceptable for a lot of games. Sure there are titles where this won’t be an issue but cutting off a large section of the market (FPS, RTS, RPGs and any mix of them inbetween) further reduces the viability of any potential cloud gaming service.

In fact for many of the titles that could benefit from a cloud gaming service can already be ported to the web thanks to things like Unity or the use of OpenGL extensions in HTML5. Indeed many of the games that I could see being published on a cloud platform (casual MMORPGs, turn based strategy games, etc.) wouldn’t be much different if they were brought to the traditional web instead. Sure you lose some of the platform agnosticity because of this but you can arguably reach the same number of people using that as you could with a cloud platform.

User expectations are also set rather high for cloud services with many of them being flat fee, unlimited usage scenarios (think Pandora, NetFlix, etc). The current business models for cloud gaming didn’t gel well with this mindset as you were paying for the games you wanted to play (often cheaper than retail, sometimes not) for a limited period of time, akin to a long term rental. Whilst this works for some people most users will expect to be able to pay a flat fee in order to access a catalogue they can then use at their leisure and this has significant ramifications for how publishers and developers will license their games to cloud developers. It’s not an insurmountable problem (the music industry came around eventually so the games industry can’t be far behind) but it does introduce a market dynamic that cloud gaming services have not yet investigated.

With all these things being considered I find it hard to see how cloud gaming services can viable in the near term as whilst all the issues are solvable they all work against delivering something that can turn you a profit. Cloud GPUs, ever increasing quality of Internet connections and the desire by many to migrate completely to cloud based services does mean that there’s a trend towards cloud gaming services becoming viable in the future however the other, fundamental limitations could see those pressures rendered null and void. This is something I’m willing to be proven wrong on though as I’ve invested myself heavily in cloud principles and I know that its capable of great things. Whether cloudifying our gaming experience is one of them is something that I don’t believe is currently feasible however and I don’t see that changing for a while.

Google’s Peculiar Flash Obsession.

Google is one of the biggest proponents of an Internet that’s unencumbered by proprietary standards, patents and non-neutral traffic routes. That’s been a great boon to us Internet users as their advocacy on our behalf means that as long as they stay in business we’re likely to continue to have an Internet that stays true to those ideals. Of course like any company they’re not entirely perfect, at times attempting to forward their own agenda under the guise of openness, but overall their contribution to keeping the Internet free and open has been positive. It seems rather odd then that Google has an obsession with Adobe’s Flash product, to the point where I wonder if there’s something going on that I don’t know about.

Back in March last year Google announced that they were integrating the Flash plugin directly into their Chrome browser. This was at the height of the web standards war that was raging between Apple and Adobe so it was easy to construe Google’s support of Flash as them taking Adobe’s side in the matter. That notion was further reinforced by the fact that Google’s Android platform fully supported Flash as well. This level of support for a proprietary plug-in for a company that prides itself on being a big supporter of open standards seems rather hypocritical, but there are some reasons as to why they’re doing it.

One of Google’s main objectives in developing the Chrome browser (and subsequently releasing the vast majority of its source code) was to improve the Internet experience for the end user. A lot of effort was focused on developing a much faster JavaScript engine, dubbed V8, that would significantly speed up many of the JavaScript heavy websites that now dominate the web. The integration of Flash into Chrome then was the next step in making the Internet as a whole more usable as the liberal use of Flash on many websites can bring even the most powerful PC systems to their knees. The same sites wreck absolute havoc on mobile handsets so it was definitely in Google’s interest to get more closely acquainted with Flash, if only to make it more usable.

Recently though it appears that Google’s support of Flash was actually leading up to a much more ambitious goal, transitioning the web from Flash to a HTML5 future:

Google is enabling developers who use the Adobe Flash Professional developer tool to convert their animations to HTML5 via an extension based on Google’s Swiffy conversion technology.

“One of our main aims for Swiffy is to let you continue to use Flash as a development environment, even when you’re developing animations for environments that don’t support Flash,” said Esteban de la Canal, Google software engineer, in a blog post. “To speed up the development process, we’ve built the Swiffy Extension for Flash Professional. The extension enables you to convert your animation to HTML5 with one click (or keyboard shortcut).”

Now it’s interesting that Google would go ahead and do something like this when Adobe had already made their play in this field with their Wallaby product. The big difference here is that Wallaby was specifically targeted at Flash Ads only and didn’t support many of the features that made Flash so versatile, like ActionScript. Swiffy on the other hand does support ActionScript and several other features that weren’t present in Wallaby. It would seem then that Google thinks they can do better than Adobe at their own game which they very well could especially when Adobe just recently announced that they weren’t working on mobile Flash any more.

Of course the transition from native Flash to Flash rendered through HTML5 doesn’t necessarily mean we’re looking at a future web that performs better. The main problem with Flash wasn’t so much the platform it was the developers on that platform. The Flash ads were the biggest culprit, often laden with gobs of unnecessary and bloated code that were the source of the performance problems people encountered. Transitioning such ads to HTML5 won’t make that code go away (there is a chance to optimize, but automated tools can only go so far) and the result will more than likely be just as bad as the original Flash it came from. It’s a step in the right direction yes, but it’s not going to be an all roses future like some would have you believe.

It’s quite interesting to see the kind of games that Google plays in order to make the web better for everyone. At times they may seem to be on the wrong side but it’s becoming clear that they’re playing the long game for a better web for everyone. It will be interesting to see how common Swiffy converted Flash files become and whether they’re still the performance hogs that their predecessors are but knowing Google they won’t let it lie until they’ve optimized it to the nth degree. Adobe’s reaction to Swiffy will be telling as well considering they’re now competing directly with Google on their home turf. The end result will be a better, more open Internet for us all something I think we can all agree is a good thing.

So Long Flash and Thanks for all the Vids.

You’d be forgiven for thinking that I was some kind of shill for Adobe what with all the pro-Flash articles I’ve posted in the past. Sure I’ve taken their side consistently but that’s not because of some kind of fanboy lust for Adobe or some deep rooted hatred for Apple. More it was because the alternatives, HTML5 with CSS3 and JavaScript, are still quite immature in terms of tooling, end user experience and cross platform consistency. Flash on the other hand is quite mature in all respects and, whilst I do believe that the HTML5 path is the eventual future for the web, it will remain as a dominant part of the web for a while to come even if it’s just for online video.

Adobe had also been quite stalwart in their support for Flash too, refusing to back down on their stance that they were “the way” to do rich content on the Internet. Word came recently however that they were stopping development on the mobile version of Flash:

Graphics software giant Adobe announced plans for layoffs yesterday ahead of a major restructuring. The company intends to cut approximately 750 members of its workforce and said that it would refocus its digital media business. It wasn’t immediately obvious how this streamlining effort would impact Adobe’s product line, but a report that was published late last night indicates that the company will gut its mobile Flash player strategy.

Adobe is reportedly going to stop developing new mobile ports of its Flash player browser plugin. Instead, the company’s mobile Flash development efforts will focus on AIR and tools for deploying Flash content as native applications. The move marks a significant change in direction for Adobe, which previously sought to deliver uniform support for Flash across desktop and mobile browsers.

Now the mobile version of Flash had always been something of a bastard child, originally featuring a much more cut down feature set than its fully fledged cousin. More recent versions brought them closer together but the experience was never quite as good especially with the lack of PC level grunt on mobile devices. Adobe’s mobile strategy now is focused on making Adobe AIR applications run natively on all major smart phone platforms, giving Flash developers a future when it comes to building mobile applications. It’s an interesting gamble, one that signals a fundamental shift in the way Adobe views the web.

Arguably the writing has been on the wall for this decision for quite some time. Back at the start of this year Adobe released Wallaby, a framework that allows advertisement developers the capability to convert Flash ads into HTML5. Indeed even back then I said that Wallaby was the first signal that Adobe thought HTML5 was the way of the future and were going to start transitioning towards it as their platform of the future. I made the point then that whilst Flash might eventually disappear Adobe wouldn’t as they have a history for developing some of the best tools for non-technical users to create content for the web. Indeed there are already prototypes of such tools already available so it’s clear that Adobe is looking towards a HTML5 future.

The one place that Flash still dominates, without any clear competitors, is in online video. Their share of the market is somewhere around 75% (that’s from back in February so I’d hazard a guess that its lower now) with the decline being driven from mobile devices that lack support for Flash video. HTML5’s alternative is unfortunately still up in the air as the standards body struggles to find an implementation that can be open, unencumbered by patents and yet still be able to support things like Digital Rights Management. It’s this lack of standardization that will see Flash around for a good while yet as until there’s an agreed upon standard that meets all those criteria Flash will remain as the default choice for online video.

So it looks like the war that I initially believed that Adobe would win has instead seen Adobe pursuing a HTML5 future. Its probably for the best as they will then be providing some of the best tools in the market whilst still supporting open standards, something that’s to the benefit of all users of the Internet. Hopefully that will also mean better performing web sites as well as Flash had a nasty reputation for bringing even some of the most powerful PCs to their knees with poorly coded Flash ads. The next few years will be crucial to Adobe’s long term prospects but I’m sure they have the ability to make it through to the other end.

Silverlight May Die, But the Developers Won’t.

You’d think that since I invested so heavily in Silverlight when I was developing Lobaco that I would’ve been more outraged at the prospect of Microsoft killing off Silverlight as a product. Long time readers will know that I’m anything but worried about Silverlight going away, especially considering that the release of the WinRT framework takes all those skills I learnt during that time and transitions them into the next generation of Windows platforms. In fact I’d say investing in Silverlight was one of the best decisions at the time as not only did I learn XAML (which powers WPF and WinRT applications) but I also did extensive web programming, something I had barely touched before.

Rumours started circulating recently saying that Microsoft had no plans to develop another version of the Silverlight plugin past the soon to be released version 5. This hasn’t been confirmed or denied by Microsoft yet but there are several articles citing sources familiar with the matter saying that the rumour is true and Silverlight will recieve no attention past this final iteration. This has of course spurred further outrage at Microsoft for killing off technologies that developers have heavily invested in and whilst in the past I’ve been sympathetic to them this time around I don’t believe they have a leg to stand on.

Microsoft initially released Silverlight back in 2007 and has release updates to the platform every year or so since then. Taking that into consideration you’d figure that the latest release of Silverlight has 1 or 2 years in it before other technologies (most likely HTM5 and JavaScript) overtake it in terms of functionality. In that time Windows 8 will be released along with WinRT, the framework that will be instantly familiar to any Silverlight developer. Sure the code might not be directly translatable to the new platform but considering the design work is done in XAML and C# is a supported language I’d struggle to find any Silverlight developer who wouldn’t be able to blunder their way through with a couple Google searches and a StackOverflow account.

All of Microsoft’s platforms are so heavily intertwined with each other that it’s really hard to be just a Silverlight/WPF/ASP.NET/MFC developer without a lot of crossover into other technologies. Hell apart from the rudimentary stuff I learnt whilst in university I was able to self learn all of those technologies in the space of a week or two without many hassles. Compare that with my month long struggle to learn basic Objective-C (which took me a good couple months afterwards to get proficient in) and you can see why I think that any developer whining about Silverlight going away is being incredibly short sighted or just straight up lazy.

In the greater world of IT you’re doomed to fade into irrelevance if you don’t keep pace with the latest technologies and developers are no exception to this. Whilst I can understand the frustration in losing the platform you may have patronized for the past 4 years I can’t sympathize with an unwillingness to adapt to a changing market. The Windows platform is by far one of the most developer friendly and the skills you learn in any Microsoft technology will flow onto other Microsoft products, especially if you’re proficient in any C based language. So whilst Microsoft might not see a future with Silverlight that doesn’t mean the developers are left high and dry, in fact they’re probably in the best position to innovate out of this situation. 

Windows 8: The Death of the Silverlight Ecosystem?

It’s only been just over a week since Microsoft demoed their latest iteration of the Windows platform but in that short amount of time it’s already managed to stir up quite a bit of discussion from friends and foes alike. The foes were quick to call out the new OS’s tablet envy, conveniently forgetting Microsoft’s rhetoric that the next version of Windows after 7 was going to have a much more web centric focus, with the possibility of it being entirely cloud based. More interesting however is the discussion arising from long term developers on the Microsoft platform, and it’s not the kind of adulation and praise you’d normally expect.

During the D9 conference Microsoft said that the new tile mode in Windows 8 was based around HTML5 and Javascript applications. Whilst they did mention that all current apps built on the .NET platform should run as intended when running in the familiar desktop mode they made no mention of whether or not the .NET and Silverlight platforms could be used to create applications in the new style of interface. With Microsoft traditionally being quite favorable to developers the notion of having to re-skill to HTML5 and Javascript (not to mention reworking existing codebases) came as quite a shock to a lot of developers and their reaction was akin to an open revolt on the forums.

Rampant speculation soon followed and wasn’t helped by the fact that Microsoft has asked everyone to remain calm until their BUILD developer conference in September. It’s not the first time this sort of thing has happened either, a similar level of hubbub was roused when Microsoft was coy about Silverlight’s future when talking about Internet Explorer 9 and it’s dedication to web standards. They soon came out saying that they still saw a future in Silverlight, especially for the Windows Phone 7 platform, but many of them were left unconvinced. It’s then quite likely that this second round of doubt that Microsoft has cast over their third party developer’s futures was the straw that broke the camel’s back and all the blame is being leveled squarely at Microsoft.

For what it’s worth I feel their concerns are valid if the reaction to them is somewhat overblown. Microsoft has a long history of eating its own dog food and many of their client facing applications are built upon the technologies that so many are worried are going to disappear in the near future. The best example of this is their Windows Azure management console which is built entirely on Silverlight. Couple that with the fact that Microsoft has many partners with a very heavy investment in the platform and I find it hard to jump on the “Silverlight is dead” bandwagon, but that doesn’t necessarily mean Microsoft is committed to bringing Silverlight into the Windows 8 tablet world.

Sure it would be great to be able to create Silverlight applications on the new Windows 8 tile system and Microsoft would be leveraging off a lot of preexisting talent to help drive adoption of the platform. However it would also hinder Microsoft’s adoption of web standards, as many developers would favor using proprietary Microsoft technologies instead of attempting to reskill. They’d then be the slave of two masters: on the one hand the Silverlight crowd demanding ever more features and tools that are constrained to that platform and on the other the web standards crowd that has been Microsoft’s bug bear ever since alternative browsers started to gain real market traction. It’s not like Microsoft doesn’t have the resources to deal with this though, but I can understand their motivations should they want to eschew Silverlight in favour of a more standard environment.

So is this the end of the line for the Silverlight ecosystem and the developers who built their skills around it? Hard to say, with Microsoft being mum on it for the next few months we’ll just have to play it by ear until we get more information from them. In all honesty even if they do end up dropping Silverlight for HTML5 and Javascript I’d expect that the next release of Visual Studio would bring enough tools and resources with it to make the transition much easier than everyone is making it out to be. Hell if Adobe can build a Flash to HTML5 converter then it’s quite possible for Microsoft to do the same for Silverlight, even if that’s just a band-aid solution to satisfy developers who refuse to reskill.

 

My Windows Phone 7 Dilemma.

You know I was pretty hyped about getting a WP7 handset after having a short play with one in the store. The slick interface and overall usability of it was so high that I thought it was worth a shot and I had really nothing to lose since my work would be paying for it. The NoDo update was on the horizon however so I decided that I’d hold back until it made its way into production so that I wouldn’t have to deal with the same frustrations that day 0 customers had. Most notably this would be the inclusion of copy and paste, but there were also a few other fixes that I thought would be good to have and worth the wait.

The problem is however that unlike regular Windows patching there’s a gate keeper between me and Microsoft’s patches for their new mobile platform. You see the patches have to pass muster with the carriers first before they can be distributed to the handsets although Microsoft had said in the past that they were working with them to make the process as quick as possible. Unfortunately for us Australian customers looking for a WP7 handset you really only have one carrier to go with: Telstra. Now this wouldn’t be so much of a bad option normally since Telstra had to start playing straight after their retail and wholesale arms were broken apart but it seems that they’re not up to the job of testing WP7 updates:

Universal availability of the copy-and-paste update to Windows Phone 7, codenamed NoDo, is almost here, according to Microsoft’s latest schedule update. The final unpatched phone available in the US market, the HTC Surround sold by AT&T should start to receive its updates within the next ten business days. The network’s other two handsets, the Samsung Focus and LG Quantum, have been receiving updates since last week.

European carrier Deutsche Telekom (which includes T-Mobile UK) has at last finished its testing, as has Australian carrier Optus. Updates from phones on these networks should also appear within the next ten business days or so. This leaves only two carriers still delaying the updates due to “testing”: Telefonica, in Spain, and Telstra, in Australia.

This was the one area where I was expecting Microsoft to shine through since their bread and butter products have depended so heavily on their patch services for well over a decade. Sure the vast majority of the blame should be leveled at the carriers since they’re the ones causing the delays, but Microsoft isn’t innocent of incurring delays either. Of course the original iPhone and Android handsets weren’t immune to problems like this either but I had expected Microsoft’s late coming to the party to be at least coupled with a strong patch and feature release scheme so they could play catch up quickly.

It might seem like an extraordinarily small gripe considering the rest of the platform looks solid but when minor feature releases like this take so long to get through the pipeline it makes me wonder just how long I’ll have to wait for the next update, codenamed Mango, to drop. Amongst other things Mango will bring full HTML5 support to WP7 something which it currently lacks in its browser. Whilst the IE9 implementation of HTML5 does leave some things to be desired (my newest app idea uses HTML5 bits, and IE9 mangles it) it is a lot better than not having it at all, especially when so many mobile versions of sites rely on HTML5 functionality. With speculation now brewing that this update might slip to next year that’s starting to put WP7 at a serious disadvantage, unless some enterprising browser developer ports to WP7 ala Opera et al.

I’m still planning to nab myself one of these handsets if only for the few times I’ll want to try my hand at developing an application for it but with such delays piling up on each other I could very well see myself changing to Android or back to iOS until they’re finished playing the catch up game. I’m sure as time goes on they’ll develop a much better relationship with the carriers and hopefully they’ll be able to leverage that to remove some of the roadblocks to getting patches and updates out to us consumers. Until then however WP7 users are going to be at the whim of the carriers, even more so than they are normally.

Adobe’s Wallaby: And You Thought HTML5 Would Save You.

Adobe and Apple haven’t been the best of friends for a while now. Whilst many of their products are still considered some of the most top of the line applications available on the OS X platform Apple couldn’t be more hostile to their most popular product: Flash. Now this isn’t without good reason as Flash has a terrible tendency to be abused by sloppy developers (most of the time ad networks) who can even bring a full blown desktop PC to its knees. Keeping Flash out of their handhelds meant fewer headaches for them and forced the hand of many companies to rethink their use of Flash, lest they draw the ire of the iOS browsing crowd.

Whilst there was a good few months of to and fro between these two companies last year it all subsided once Apple capitulated to the developer community that raised concerns over Apple’s wide reaching policy on cross platform libraries. This seemingly opened up the door that Apple had shut in Adobe’s face, enabling them to create a product that could convert Flash files into a more iOS friendly format. A couple days ago they announced the first iteration of the product, called Wallaby:

Welcome to the Wallaby Technology Preview. Wallaby is an application to convert Adobe Flash Professional CS5 files (.FLA) to HTML5. Wallaby has a very simple UI which accepts as input a FLA file and exports HTML and support files to a user-selected folder. There is also an option to launch the default application assigned for the .html extension.

The announcement has, of course, caused quite a stir in the tech community. Most of them focus on the fact that Wallaby was designed with only one purpose in mind: to get Flash banner ads working on iOS devices. As such Wallaby is pretty limited in the functionality it provides, being unable to convert things like ActionScript which enable things like Flash based games. Of course this also raises the issue that Flash is most often abused by advertising agencies with poorly coded banner ads being one of the main culprits. Whether or not badly coded ads in Flash translate into bad (or worse) ads in HTML5 remains to be seen, but I can’t see how they could get any better.

Realistically the issues that many people associated with Flash aren’t really caused by it. More it is those who use the platform that are to blame for the troubles that many people encounter with it. This is why I didn’t understand Apple’s position on Flash in the first place. Sure there are many banner ads out there that can make your web experience a browsing hell but banning one technology simply drives those same people to look for other platforms, it won’t magically make them better developers overnight. Wallaby is a great example of this as those same people that created poor performing Flash ads can now do the same in HTML5. In the end Apple is merely delaying the time in which it takes for the same problems that plagued Flash to come to their iOS platform. Google I feel has is on the right track to solving this problem, tightly integrating Flash into their products so they can tune it properly.

It does show that Adobe doesn’t believe the future is still with their Flash platform and the gears are in motion to transition to the new world of HTML5. There’s a reason why Flash has been such an integral part of the web for so long and it’s simply because Flash gave the best tools for non-technical users to create rich content for the web. Whilst they’ve come rather late to the mobile boat they are one of the few companies that has the momentum and devoted user base to make the switch successfully. I’m sure many people will see this as them “capitulating” to Apple’s demands but in reality its anything but and I’m sure they’ll eventually dominate the HTML5 space just as they’ve done in the past with Flash.

 

HTML5, Video and The War For Web Standards.

Whenever I find myself in the depths of coding for a mobile handset or browser HTML5 always seems to be the panacea to all my problems. Its promises of cross platform compatibility and ability to leverage the vast amount of work already done with Javascript has seen me lose several weeks of productivity in the hopes of forgoing much more work later on.  It always ends the same way with me getting some rudimentary functionality working before trying it in a different browser and seeing all my work fall in a screaming heap, forcing me to do the work I had so aptly delayed. The source of this problem is that whilst HTML5 may one day be the norm for how web pages are done on the Internet it is still a work in progress and the implementation of the standards vary from browser to browser.

This lack of standard implementation across the browser market is just another form of a format war. Whilst they might all appear to be collaborating on the future of the web realistically they’re all fighting for their version of the web to become the standard. No longer is a company able to release a product like IE6 onto the market that plays fast and loose with the standards in favour of delivering more functionality as that will more than likely end up being ignored by the web development community. Now the war is mostly being raged through standards committees, but that doesn’t mean the same old strong arming tactics aren’t being used.

Last week Google announced that it would no longer be supporting the H.264 codec for the HTML5 <video> tag. The post triggered wide spread discussion about the future of the HTML5 standard and Google felt the need to clarify its position:

Why is Google supporting WebM for the HTML tag?

This week’s announcement was solely related to the HTML tag, which is part of the emerging set of standards commonly referred to as “HTML5.” We believe there is great promise in the tag and want to see it succeed. As it stands, the organizations involved in defining the HTML video standard are at an impasse. There is no agreement on which video codec should be the baseline standard. Firefox and Opera support the open WebM and Ogg Theora codecs and will not support H.264 due to its licensing requirements; Safari and IE9 support H.264. With this status quo, all publishers and developers using the tag will be forced to support multiple formats.

On the surface it would appear that Google is attempting to use its share of the browser market to put some pressure on the HTML5 standards committee to make WebM or Theora the default codec for <video> tag. For the most part that’s true and should they get their way Google will have control over yet another aspect of the web (in contrast to now when they’re just the dominating player thanks to YouTube). However whilst such a move might at first appear to only benefit Google, Mozilla and Opera I believe that a push away from H.264 is beneficial for everyone on the web, except for Microsoft and Apple.

You see whilst there’s no official agreement on what the default codec should be for HTML5 there are in fact 2 groups within the standards committee that agree wholeheartedly on which one should be the standard. Google, Mozilla and Opera all believe that WebM or Ogg Theora (or both!) should be the default standard whilst Apple and Microsoft both want H.264. The reason behind that is quite obvious when you look at the patent body responsible for licensing the H.264 technology, the MPEG-LA. Both Apple and Microsoft are have patents in the MPEG-LA patent pool meaning they have a vested interest in making it the default standard. This is the main reason why having H.264 as the default is bad Internet users and web standards as it would force anyone who develops HTML5 products using video to license the H.264 codec, something which could be quite devastating to early stage start ups. Additionally it encumbers what should be a completely open and free standard with licensing requirements, something that hasn’t been present in any web standard to date.

Whilst the decision doesn’ affect me directly, no matter which way it goes, I can’t support something that has the potential to stifle innovation like a licensing requirement does. Google throwing its weight behind its own and other open codecs has highlighted the issue succinctly and hopefully this will lead to more productive discussion around which (if any) codec will become the standard for HTML5. We’re still a long way from having a fully formalised version of HTMl5 that anyone can implement but it’s good to see some movement on this front, even if it’s just one web giant poking the trolls.

Procrastination Takes Many Forms.

I really can be my own worst enemy sometimes. It’s been almost a month since I got back from the USA and despite the best of intentions I haven’t really done that much work on Lobaco apart from a little work on the API and web UI. Whilst I was pretty sure I wasn’t going to hit the code hard immediately after touching back down in Australia I still thought that after maybe a week or two of lazing about the coding bug which had firmly bitten me before I left would take a hold once again, pushing me to build on the momentum I had set up. Sadly it wasn’t to be and instead I just resided myself to feeling guilty about what I should’ve been doing and pulling the meter tall weeds that had grown in our front yard.

Partly to blame is that sense of perspective I get whenever I take time away from a project to work on something else or to just have a break. Usually the first thing that pops into my head is “why the hell should I bother” and I’ll spend a good chunk of time focusing on the negative aspects of whatever I’m doing. After a while though I’ll just try to do a feel small things, a few quick wins to get me back into the mindset of getting things done. After that it’s usually pretty easy going (this usually takes about 2 weeks) until I hit a wall again or I feel like getting my weekends back for a while so I can relax and get my head back together. The last few iterations of this cycle are what lead to the 3 major revisions of what is now Lobaco.

This time however was different. After being back for 2 weeks and being firmly thrust back into the world that had barely changed since I had left (even though I expected it to be wildly different,  for some reason) I still really couldn’t get into coding without feeling like I should be doing something else. My usual routine of getting a couple quick wins with the API and web UI didn’t translate into jumping back onto my MacBook and smashing out some iPhone code. Instead I started wondering whether or not a native client was the way to go and the possibility of doing a web based client for the phone itself. I had been down this road before and ultimately found that whilst iPhone programming was a world away from I’d done before the progress I had made with only a couple weeks of effort was far more encouraging than the same amount of time spent trying to wrangle HTML5 and Javascript into something workable.

Then along came Sencha.

I was going through my 700+ post backlog of Techcrunch articles when I came across this one about Sencha, a web startup that just released their Touch framework which provides the basis for building native looking applications in HTML5 and Javascript. Thinking this might be my salvation to writing native clients for all handsets I quickly downloaded the framework and started hacking around to get something workable. I was able to get the example running in one weekend and made a few modifications but I didn’t get into the real meat of it until last Friday night. After managing to replicate the UI I had built in objective-c within the Sencha framework I uploaded it to my web server to see what it would look like on the iPhone and instantly I realised what was wrong.

This client was just an elaborate way of procrastinating.

Now whilst the client looked decent and didn’t take too much to set up it didn’t look anywhere near as good as my native app nor could it hold a candle to its performance. Sure my hack job probably ensured that the performance wasn’t as good as it could be but in comparison to the native client hack job I did it was pretty stunning. After coming to that realisation I booted up my MacBook to start getting acquainted with Xcode again and spent last weekend coding up some performance improvements¹ for it which I had put off before I left for the USA. I’m sure this won’t stop me from looking at going down that path in the future but I can at least rest easier now that I’m feeling the urge to program once again.

It’s been a weird learning experience for me since I’m usually pretty good at knowing when I’m procrastinating. Usually I have a good reason for it (like having 1 bit of work to do and not doing it since it’s not due for months) but this is the first time I caught myself doing something I thought was useful when really I was just making excuses for doing the work I knew needed to be done. With a good week of holidays coming up over the Christmas/New Year period this realisation couldn’t have come at a better time and I’m looking forward to making the most of my time off with the hope that the momentum will carry me on into the new year.

¹I’m going to do a big post about this hopefully tomorrow. I hit some really, really esoteric problems getting everything to work but I have and the results are, to put it bluntly, bloody amazing.

Web Standards: They All Have Their Agenda.

It really should come as no surprise that anything a large corporation does is usually done in their best interests. By definition their existence is centered around increasing profit for their respective shareholders within the bounds of the law and operating outside that definition will in turn make your company not long for this world. Still we manage to suspend disbelief for certain companies which have qualities we aspire to but make no mistake they are in the end driven primarily by motives of profit. Nearly all other secondary activities are conducted to further their primary directive, even if on the surface they don’t appear that way.

Take for instance the current web standards warthat’s brewing between Apple and Adobe. Whilst both companies would have you believe that their stance is the only answer to the problem the fundamental issue that they face is not one of ubiquitous web standards, more it is about control over the future of the Internet and who will be the dominant player. I’m on record as stating that Adobe will win out thanks to its current market penetration and support from many big players. It’s no secret that Google is more on Adobe’s side in this war than Apples, as a recent post from one of their (well their subsidiary) employee states:

There’s been a lot of discussion lately about whether or not the HTML5 <video> tag is going to replace Flash Player for video distribution on the web. We’ve been excited about the HTML5 effort and <video> tag for quite a while now, and most YouTube videos can now be played via our HTML5 player. This work has shown us that, while the <video> tag is a big step forward for open standards, the Adobe Flash Platform will continue to play a critical role in video distribution.
It’s important to understand what a site like YouTube needs from the browser in order to provide a good experience for viewers as well as content creators. We need to do more than just point the browser at a video file like the image tag does – there’s a lot more to it than just retrieving and displaying a video. The <video> tag certainly addresses the basic requirements and is making good progress on meeting others, but the <video> tag does not currently meet all the needs of a site like YouTube:
All of the points Harding make add quite a lot of fuel to the fire in the whole web standards debate. He’s quite right that the current version of HTML5 does not (and most like can not) provide the features required by sites like YouTube. As such there will always be a need for plugins that fill the functionality gap between the web standards and what is technically possible. The more rich the standards are the less requirement there is for plugins but as it stands right now the features provided by third party plugins are almost a necessity for a lot of sites on the Internet and it will be a long time before the standards catch up.
However if you read on you’ll see that YouTube’s apprehension to switch over to a full HTML5 based site is fueled not only by lack of features but also because their bread and butter, videos, still lacks agreement on some core components. One of those is the codec that will be used as the standard for all content used with the <video> tag. Usually you would go with the most popular codecs out of the lot which is currently H.264. The problem with that codec is that, while it is currently royalty free, it is encumbered by a number of patents held by a consortium of companies. This poses a problem for browser developers as it means eventually they will have to pay fees to implement the video part of the web standard, which doesn’t really fit with overall vision of the HTML5 standard. Google of course has their own open codec VP8 which they’ve garnered support for which brings us full circle back to my original point: they’re only developing it to further their bottom line.
Ultimately it will be the market that decides the winner out of all this. Web standards will always lag behind what Internet enabled devices are capable of and that will mean there will have to be third party plugins to bridge the gap. Whether that gap is bridged by Adobe, Apple or some other company remains to be seen but so far the market still seems to side with Adobe as the vast majority of sites (including this one) make use of Flash in one way or another. Many sites will still go to the effort to make their content more accessible to mobile devices (like this one!) but in the end we’d still have to do that even if Apple ends up losing the war on Flash.
I guess what I’m trying to say is: if a company tells you they’re doing something that seems to be for your benefit ask yourself what they have to gain from doing it. In the end you’ll notice that they will be benefiting from it far more than you ever could.