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.

There has been lots of buzz and some really interesting bits coming out so far including Silverlight 4 RC, Internet Explorer 9 preview (with HTML5 and CSS3 etc.), Windows phone information, etc.

Scott Hanselman has posted a great roundup of the announcements and keynotes.

Rumour on the street has it that, finally, the investment banks are going to start abandoning IE6. Barclays are allegedly going to do an enterprise-wide rollout of IE8 in Q2 of this year (put back from Q3 last year). Even more surprising (and impressive) is a rumour that Standard Bank of South Africa are going to ditch Microsoft browsers completely and move to Chrome for their corporate standard!

This is no mean feat for a complex, high performance, low latency trading portal framework written in JavaScript and running to >250KLOC. Although IE8, Firefox, Safari and Chrome are similar enough to make it relatively straightforward to support each of them, IE7 and, particularly, IE6 are a different story. They are riddled with quirks and bugs in their layout, rendering and memory management engines. In addition, developer tool support is starting to lag. Worst of all, their performance is diabolical compared with the recent crop of competitors.

However, IE6 is often one of our customers’ main target browsers by default. Sadly the big financial institutions, and to a lesser degree their clients, run with locked-down and often out-of-date desktop components. This limits their capacity to upgrade or install new browsers, though it’s true that some of the smaller firms are able to do so more easily.

So, should we continue to support IE6? How should we encourage our customers and users to move to newer browsers? What are the benefits of doing so?

Why support IE6?

A large amount of engineering effort has to go into making Caplin Trader components behave and perform well in IE6. To say our developers would rather see it burn in hell is an understatement. A number of them use RobotJohnny’s amusing cartoon for their desktop background, and  I even recently discovered on of our teams had sneaked a joke story card onto their board entitled “Drop Support for IE6″ signed by all the developers!

On the other hand our customers need us to support IE6, at least for the time being.  There may be some light at the end of the tunnel as I have heard that a couple of large international investment banks are planning to mass roll-out IE8 by the end of the year.

So in answer to the first question, yes, we will continue to support IE6 for the foreseeable future. Given this, what are the considerations we need to make to do this and how can we encourage users to upgrade?

IE6 performance

Here’s a graph, compiled last September by John Resig, of comparative JavaScript performance across different browsers. You can clearly see that IE7 (he didn’t even bother with IE6!) is an order of magnitude worse than most of the current browsers:

JS Perfomance comparison

One clear benefit of our continued support for IE6 is that it forces us to produce components and libraries that perform well in that browser. All of our automated functional and performance tests are run across a range of browsers, but IE6 is considered the baseline – if it doesn’t work or perform in IE6 it’s not good enough!

This means that in the newer browsers Caplin Trader literally flies. Using it in FF3.5 or Chrome is really something – faster and more responsive than a lot of desktop apps I use every day!

Getting the most out of Caplin Trader

It’s one thing for our developers to enjoy Caplin Trader at its best, but really we want the end users to have this enhanced experience too! We’ve been experimenting with the best way to encourage them to move onto a newer browser if they can. One approach is to detect their browser and give them an information message that encourages them to upgrade if they can. Here’s the message that’s coming in the next version of Caplin Trader:

New browser upgrade hint popup

This seems like a good, and obvious idea – tell the users to upgrade their browser! However, all is not necessarily what it seems. Mark Trammel, over at Digg, recently did some very interesting user research to try and understand why on earth there was still a steady 10% of users visiting their site using IE6. (Note – this is a retail site, our experience of financial institutions suggests that their IE6 user base is at least 40%, perhaps higher!)

The interesting result (as shown below) is that 3 out of 4 users would upgrade browser if they could:

Why do people use IE6?

This means that constantly popping up a warning that tells users to upgrade is at best annoying, and at worst may infuriate them so much they stop using the application! For this reason our dialog tries to give both an encouraging friendly message (rather than a command or a warning) and also a way to prevent future popups (a checkbox). Hopefully this provides a good balance and will encourage users that can to upgrade, and those that can’t to put pressure on their IT departments to do so for them…

Poison chalice or holy grail?

In summary, there is a clear cost in engineering effort (not to mention developers’ hairlines!) to continuing supporting IE6. But this is currently outweighed by the benefits of ubiqutous reach and the fact that targeting a browser that’s an order of magnitude slower than most of the others means we consistently produce high performing code, without allowing performance complacency to set in.