That means no more support for IE7, FF3.5 or Safari 3.

As they mention, things won’t just stop working for those browsers, but they won’t be officially supported.

It looks like there would be some administration overhead to set this up so the old sites/applications specify that they need to run in IE6 mode, but at least this gives people an option of running a newer browser. This put the responsibility in the hands of the users (or administrators) of old in house applications that require IE6 rather than in the hands of the software vendors writing new exciting applications that at the moment have to spend a lot of effort being compatible with IE6.

With Internet Explorer, Microsoft seem to be always playing catchup – not only with the fact that their latest version is usually a bit behind, but also because only a small number of people upgrade to the latest version. This time round only a subset of IE users are even able to upgrade, due to lack of XP support.

Hopefully with the current trends towards HTML5 and native web people will be encouraged to upgrade, despite the obstacles put in the way.

Will IE9 help us at Caplin, or other people that have struggled with supporting IE6 users for so long? Unfortunately it won’t help much.

We have mentioned problems with IE6 before, Browser wars: the ceasefire is over and Supporting IE6 – a poison chalice or the holy grail?. The problem is IE6 users in large corporations that are unable to upgrade, sometimes due to there being applications that need IE6, or they don’t want to pay to upgrade to the latest version of those applications that support newer browsers.

Could IE9 entice them though? Microsoft seem to be quite keen on HTML5 now, maybe people will be encouraged to upgrade? Well, yes, some people will – but the problem users on IE6 are almost certainly running Windows XP. What’s the one thing harder to get upgraded in a big corporation than IE6? The operating system, and guess what, IE9 is not supported on Windows XP.

So people stuck on IE6 are probably stuck on it for even longer now if they are on Windows XP – apart from those corporations that will upgrade to IE7 or IE8, which is their only option if they are on XP and not able to move to Firefox or Chrome.

I have an iPhone and based on most things I use, native iOS apps are much better than web apps – but I don’t think that is all down to technical reasons. You can create very ‘app’ like web apps for iPhones and iPads – mobile Safari is a very good browser and with the various HTML 5 features and a bit of effort web apps can work very nicely. The problem is that last part – it takes a bit of effort and most people aren’t making that effort.

Of course creating a native iOS app takes some effort too, and an investment into a relatively closed environment. Despite this there are a huge number of iOS applications out there, the large numbers quoted are a bit misleading since most apps are a complete waste of time.

The other issue with native vs web is that if you want to target multiple devices you need to create multiple native versions – this is the biggest advantage that a web app has – with a lot less effort you can create something that will work across devices.

An interesting site has popped up, openappmkt.com which is a collection of web apps, targeted for iPhones it seems, and making installing web apps an experience close to the real app store. Apple does have its own web app section on their website at http://www.apple.com/webapps/ too.

I am still fairly open minded about all this and we are working on solutions for both native and web.

I also noticed that the new Blackberry 6 OS on the Blackberry Torch has a webkit based browser, which should make things better for web apps – however, if targeting Blackberry you can’t rely on people being on this version.

Some interesting links on the subject:

http://www.quirksmode.org/blog/archives/2010/03/html5_apps.html

http://www.quirksmode.org/blog/archives/2010/04/mobile_web_or_o.html

Does Tab Candy signal the slow death of the tab?

It’s a strange turn of phrase, but as we do more and more online keeping tabs on everything and segregating areas of interest is becoming a more and more frustrating and complicated task when using the tabs within a web browser.

We need a way to organize browsing, to see all of our tabs at once, and focus on the task at hand. In short, we need a way to get back control of our online lives.

http://www.azarask.in/blog/post/tabcandy/

Tab Candy for Firefox shows another way with groups and spaces allowing you to take back control of your web browser’s tabstrip.

Grouping related tabs into sets is interesting (you can also share groups across devices) it’s a shame it has to open a group back into tabs but I guess that’s the way it is… at the moment.

http://azarask.in/projects/tabcandy/movies/tabcandy-demo.mov

The shrink to a stack is nice, I wouldn’t be at all surprised to see Google come back with a Google Chrome ‘BumpTop browser view’. Towards the end of the video nesting and zooming within the spaces is also put forward.

Is this the start of a movement from web browser to a browser OS…  or will Google just wrap all this up into a Google Chrome bumpTop OS?

I’m eagerly waiting to see what Google + BumpTop come up with.

Google’s Feed API gives you access to any public Atom/RSS like data, including lots of Google’s own data. There was a lot of fuss recently about PubSubHubbub and I blogged about how PubSubHubbub is the not quite real-time web.

At Google I/O this week, Google will be announcing some changes to the Feeds API that enable updates to be pushed to browsers. ReadWriteWeb got the scoop on this posting that Google will push real-time feeds to browsers. Not just in terms of details yet, the video shows the code changes are minimal, but what is going on under the covers is what interests me. Is is really real-time? is it polling? Will they pick one, works for all, solution, or try out WebSocket for those that support it. For most things the Feed API will be used for the speed of polling is probably fine, but high frequency polling is just inefficient compared to true streaming. Long polling would sit somewhere between polling and streaming and a good compromise for the client end. What I am interested in is what implementation Google thinks is best for what could be the largest deployment of a web push service yet.

Early on in CometDaily’s lifetime I wrote a piece on the Evolution of Comet at Caplin which covers how Caplin’s core technology has evolved since the start in 1997. The article was written in 2007, so I thought I would say how things have moved on since then.

The article finishes off talking about Caplin Trader our Ajax trading front end framework. This is still a large focus for Caplin, but we have also expanded out. There is a lot of extra functionality on the backend that was developed along with Caplin Trader – higher level integration to Trading and Permissions for example. Although Caplin Trader allows you to host other RIA technologies within it, we also wanted to more openly support other client side technologies in their own right. So we worked on these APIs to create Caplin Xaqua which is the full stack of our software, from backend integration APIs, through Liberator (and Comet) out to our StreamLink client APIs, which we expanded to include .Net, Silverlight and Flex.

Coming back to Comet, with the new client APIs and also new browsers and browser versions, we improved our coverage of Comet techniques to ensure the best possible connection is made for each scenario.

And the future? Well I have blogged about HTML 5 WebSockets more than once and to reiterate, it is a good new tool for Comet server implementers (rather than people developing web applications themselves) and i’m sure when the market share for browsers supporting WebSocket grows we will be adding the capability to Liberator and Streamlink.